Vulnerability "work-around" in server?

[Xyem]

I can't think of the word I wanted so "work-around" will have to do for now, I apologise.

I require some advice in regards to server programming. I'm writing a server for my game ( which will handle both single and multi-player ) but I just realised I have coded a large vulnerability into it.

Essentially, it buffers the data it reads from clients into memory and then tries to find command "packets" ( a string ending in carriage return and/or newline ) in the buffer. However, it would be easily possible to send the server loads of data without any termination, resulting in all available memory being consumed and, I presume, the server going down.

What steps could I take to mitigate this vulnerability? I've considered limiting the size of the buffer but I don't know how I would calculate an appropriate limit.

I appreciate any suggestions.

[tinny]

Your client applications send the data in a way that will not crash the server I presume?

So you are worried about someone writing a malicious client application that will exploit this vulnerability? (denial of service attack).

Is there a way to only allow connections to the server from registered clients? E.g. Set up some sort of access control list to only accept incoming connections from known MAC addresses. This wont solve the problem but may negate some risk.

[mike_g]

What steps could I take to mitigate this vulnerability? I've considered limiting the size of the buffer but I don't know how I would calculate an appropriate limit.
Well, what are your command packets likely to contain? Just make sure your buffer is larger than the longest valid command that can be sent. It seems to me as if you're the only person that can answer that question. Or, maybe I'm missing something here.

[slavik]

looks like you need to redesign the protocol.

make the protocol send packets of stuff with predefined length.

[Xyem]

trinny:
That is exactly what concerns me. My approach to this game is that I write the server and the 'official' client ( Perl/OpenGL ) but do not limit players to that client ( so someone may write a text-based client if they wanted/needed ). Most ( if not all ) of the calculations will be done server-side to prevent cheating ( such as being able to teleport a player ).

mike_g:
This is a problem because the length of the largest valid command would change based on the parameters the server was started with ( e.g. maximum player name length, map size ). Though it may be possible to calculate the maximum size based on those..

[Xyem]

Sorry for double posting, but I had written that previous post about 7 times ( every time I scrolled up, Firefox went 'Back' ).


make the protocol send packets of stuff with predefined length.

Do you mean by having it so clients must prefix the command packet with its length? For example:
14 movePlayer 6 6

[nvteighen]

Do you mean by having it so clients must prefix the command packet with its length? For example:
14 movePlayer 6 6

I believe he's referring to force packets to have a certain length, so that everything outside the limit is discarded and not buffered.