Bug 3041 - Spoofed invalid sequence causes client disconnect
Status: RESOLVED FIXED
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: unspecified
Hardware: PC All
: P2 normal
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
Depends on:
Blocks:
 
Reported: 2007-02-28 00:00 EST by Richard Stanway
Modified: 2011-04-27 12:10:18 EDT
2 users (show)

See Also:


Description Richard Stanway 2007-02-28 00:00:45 EST 
I'll spare the copy paste and direct you to this URL:
http://aluigi.altervista.org/papers/q3noclient.txt

Seems this bug is still present in the latest versions of IOQ3.

I would also recommend the client port number be randomized on startup rather than being a fixed value to help limit the effects of this and any potentially related bugs.
Comment 1 Ryan C. Gordon 2007-05-21 11:22:30 EDT 
Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.
Comment 2 Zachary J. Slater 2008-08-08 23:59:24 EDT 
is this still a problem?
Comment 3 Ben Noordhuis 2008-08-09 06:09:43 EDT 
Yes. CL_ParseServerMessage() disconnects immediately on receiving an invalid server message. And it's trivially easy to forge a bad message if you know the IP address / range of your victim.
Comment 4 Ryan C. Gordon 2009-09-17 00:35:46 EDT 
We can change the Com_Error() that causes the drop, but if you can spoof a packet, can't you just tell the client (incorrectly) that the server is shutting down, or he's been kicked?

--ryan.
Comment 5 Thilo Schulz 2009-10-24 10:43:28 EDT 
This bug cannot be easily fixed without making the quake3 protocol incompatible.
We would need to add a message header field where the peers send some kind of key to each other so they can check for the authenticity of messages.

On a related note, it would be desirable to distinguish between old clients, and use the old protocol in this case, and newer ioquake3 clients and use a newer protocol. That would give us these advantages:

1) We can fix this security issue
2) remove all hacks currently in place to work around issues with the old protocol
3) Drop the [CL|SV]_Netchan[En|De]code stuff that used to be in place to make it harder to reverse engineer q3 protocol

To make ioquake3 server/clients use a new protocol while retaining support for the old would be very easy to do. I did that in my ioEF port already.

Timbo, Angst: how do you think about this?
Comment 6 Thilo Schulz 2011-04-20 18:45:16 EDT 
You could also start a denial of service attack if you know the user's ip who's playing. This is too much hassle to fix without breaking the protocol for questionable gain. WONTFIX
Comment 7 Thilo Schulz 2011-04-27 12:10:18 EDT 
I changed my mind. After I saw the hacks and issues around VoIP, I decided to split protocol support. Legacy support for protocol version 68 works of course.
All the new shiny, network protocol dependent features that ioq3 offers obviously will only be available to users of the new protocol, i.e. ioq3 servers and clients. But that's the way it was before anyways. Check out r1950 and r1951