Hello.

One Italian once wrote an app which shows serious vulnerability in LFS. What he has noticed is:

Quote :

====== 2) Bug ======
A fast sequence of at least two join packets causes some problems internally at the server and after some seconds it becomes unplayable and automatically restarts the match:

Quote :

Avoiding buffer overflow
BLANK : OVERFLOW - host
> HOST : Emergency Restart
Host will restart in 3 seconds

in the meantime all the other players in the server are disconnected immediately when the packets are sent.

He says that he had written LFS team about that vulnerability, but Z28 is still vulnerable. Are you going to fix it someday?

Another thing. My server is in linux (debian) box. From time to time people are being disconnected:

Quote :

FATAL TCP ERROR : CONNRESET
Lost connection to k37

What is the possible cause of that? Person gets "Don't send" box after that.

Quote from dj_hitas :

Are you going to fix it someday?

Same problems.

Don't expect anything soon. We are idiots who cannot wait 2+ years on an update

I don't even understand how hard it could be to fix that. FFS, even souce code of that application is lying on the Internet open for everyone. When you know how stuff works, you know what you can do to prevent it from working.
It's good when the server is in Ubuntu and it is possible to prevent it from working through the OS itself, but for win users.. I don't know. We are working on that at the moment, but developers should think of other people who are not as experienced in such things as we are.
Cheers.

// edit

Best not to go into further detail at this stage

Quote from dj_hitas :

I don't even understand how hard it could be to fix that. FFS, even souce code of that application is lying on the Internet open for everyone. When you know how stuff works, you know what you can do to prevent it from working.
It's good when the server is in Ubuntu and it is possible to prevent it from working through the OS itself, but for win users.. I don't know. We are working on that at the moment, but developers should think of other people who are not as experienced in such things as we are.
Cheers.

What the hell are you talking about? Where do you see the source code of the LFS server? If the source code for LFS server would have been available we wouldn't be running LFS servers on Linux hosts through wine, because I'm sure someone would port it natively to *nix already.

And bringing down the LFS server in a way described above is not affected by the OS running it. It's a bug in the LFS server, not the OS.
TCP/IP related attacks are a problem with TCP/IP stack, not with a particular OS, because TCP/IP stack is a standard used on all devices connected to the interwebz, no matter the hardware or the OS that it is running(ok, there are some variations), and TCP/IP stack is known for this vulnerability, so we won't even go there. But like said, the above bug is caused by nothing else than the LFS dedicated server it self.

Clearly "source code" refers to the malicious application, and the point was that since the method is freely available, the fix should be easy to figure out. Also, API =/= implementation in OS.

Quote from xfirestorm :

What the hell are you talking [....] It's a bug in the LFS server, not the OS.

Dooohhhh thats exactly what this is all about. Read more carefully.

Quote from NotAnIllusion :

Clearly "source code" refers to the malicious application, and the point was that since the method is freely available, the fix should be easy to figure out. Also, API =/= implementation in OS.

Yeah. I re-read it now when I'm home and I must apologize to the OP.
And I never mention "API" :P

Anyone reported this to the devs yet?

Quote :

He says that he had written LFS team about that vulnerability

If there is a new test patch I'm going to test this exploit again.

Quote from Scawen :

FIX : Some problems resulting from multiple requests to join race

This could be it.

Join race != join server .. So no.

Quote from Scawen :

Thanks for bringing that to my attention. I've made a note, investigated a little and should be able to protect against that.

Yes!

Thanks, I have now reproduced this and fixed it in my version so it will be in the test patch.

Thank you!