Network Security
by Kyle Carter · in General Discussion · 11/08/2003 (1:15 pm) · 6 replies
I'm a bit concerned about the network code; I know in Torque that under the right conditions the server can be crashed when given "naughty" data. (Basically, my knowledge of the exploit is that there are some netobjects that don't do enough sanity checking in their pack/unpack functions and be persuaded to access things they shouldn't... or you can get the server to read past the end of the packet by providing truncated data, so forth and so on.)
In my mental "roadmap", I see this as something we can put off till after the first stage of development (ie, get a product, then solve this), but it absolutely needs to be addressed at some point. It should not be possible to crash a peer by giving it weird network data - if a Torque game goes down, maybe forty people will be pissed at you, but if a peer goes down, we're looking at tens of thousands of users that get bumped off the service. Therefore, it is a major priority that we prevent this, second only to getting the product itself completed. :)
I did a read through of the core networking code, and I think that it is safe, but we need to come up with some coding practices to avoid being in the position of having many chunks of networked code to worry about fixing posthumously. An ounce of prevention...
So, perhaps Mark can address this best, but we should try to find some principles to stick to when writing net code to avoid making ourselves easily crashable. I have a feeling that this is going to be mostly common sense stuff, but let's get it out in the open.
In my mental "roadmap", I see this as something we can put off till after the first stage of development (ie, get a product, then solve this), but it absolutely needs to be addressed at some point. It should not be possible to crash a peer by giving it weird network data - if a Torque game goes down, maybe forty people will be pissed at you, but if a peer goes down, we're looking at tens of thousands of users that get bumped off the service. Therefore, it is a major priority that we prevent this, second only to getting the product itself completed. :)
I did a read through of the core networking code, and I think that it is safe, but we need to come up with some coding practices to avoid being in the position of having many chunks of networked code to worry about fixing posthumously. An ounce of prevention...
So, perhaps Mark can address this best, but we should try to find some principles to stick to when writing net code to avoid making ourselves easily crashable. I have a feeling that this is going to be mostly common sense stuff, but let's get it out in the open.
#2
11/10/2003 (10:51 am)
The script-based net code stuff I've discussed with you earlier would be a great solution to this problem, too. :)
#3
11/10/2003 (11:14 am)
Perhaps we can just come up with a checklist/style guide for now, and have a quick approval process so we double-check eachother's work. That might be sufficient to cover our butts until better things come along. :)
#4
Have a "NetworkCommand" base class as Mark says, that does packet validation, unpacking etc. and that has a virtual "execute()" method that is overriden in a subclass, that does the actual processing of the request and sends back the appropriate response.
I dont know if you have gotten a copy of my master server code from Mark (else I'll send it to you - buzz me on IRC). I have something like that implemented.
My code goes something like this (or should do after I refactor a bit):
- Requests comes into a main "connection handler"
- Spawns a thread to handle the connection
- Reads first byte to see what kind of request it is
- Fetches a command using a command factory
- Handler inputs rest of bitstream as an argument to the command
- Command takes bitstream and splits it into pieces (and could validate at this point)
- Handler fires off the execute method in the command
- Command does what its supposed to, and creates a response bitstream that is sent back to requestor
Thats basically it. Very easily extendable and clean, and easy to insert things like encryption, validation on various levels, etc.
11/11/2003 (12:35 am)
Style guide would be fine, but we can also do it better than that.Have a "NetworkCommand" base class as Mark says, that does packet validation, unpacking etc. and that has a virtual "execute()" method that is overriden in a subclass, that does the actual processing of the request and sends back the appropriate response.
I dont know if you have gotten a copy of my master server code from Mark (else I'll send it to you - buzz me on IRC). I have something like that implemented.
My code goes something like this (or should do after I refactor a bit):
- Requests comes into a main "connection handler"
- Spawns a thread to handle the connection
- Reads first byte to see what kind of request it is
- Fetches a command using a command factory
- Handler inputs rest of bitstream as an argument to the command
- Command takes bitstream and splits it into pieces (and could validate at this point)
- Handler fires off the execute method in the command
- Command does what its supposed to, and creates a response bitstream that is sent back to requestor
Thats basically it. Very easily extendable and clean, and easy to insert things like encryption, validation on various levels, etc.
#5
11/11/2003 (12:50 am)
Is your master server backwards compatable with the current master server? I'm going to need a starting point for the client GUI scripts. A server browser would be a nice small place to start.
#6
But possibly the interface from script will look much the same - e.g. registerUser(username, password, email, cdkey)
11/11/2003 (4:10 am)
Yes - as is Ben's (the GPL one) and the currently running master server from GG. I have registration and login working too, but that will most likely change a lot in this project. But possibly the interface from script will look much the same - e.g. registerUser(username, password, email, cdkey)
Associate Mark Frohnmayer