eh, that bug is the obvious one. your source is so obfuscated i cant tell exactly what it does without more examination, but all you have to do is forge udp "\xff\xff\xff\xff""connect" (c style string, duh) from the server to the server. the more interesting hole being abused actually crashes the server; it seems to trigger a bug in the command parsing code. try sending "\xff\xff\xff\xff""connect $" from any address; server chokes on it. incidentally, the four ff's at the beginning are a sequence number; the value -1 is just special, indicating an unsequenced command that can come at any time. neither packet requires the terminating null of a string; q2 probably just recv()s into a zeroed buffer or something. while we are on the subject of quake bugs, q1 has a nice one where you send a "reliable" packet on an already connected client socket with a bogus length (anything larger than 8k will likely do it) and the server dies with a random error. it is a buffer overflow, but i dont think its exploitable without a great deal of work; that buffer is not on the stack. at least to trigger that bug you either have to basically flood the target with a forged packet for each possible client connection port, or reveal your true source address; the q2 bug is only one packet, and can be sent with any sort of bogus source address. i *hope* these newest bugs were just not cleaned up because of a rushed release (have to catch those solstice shoppers), considering that the lead programmer for q2 calls himself a "network programmer". exploit code available on request. (yawn, people will make me clean up my fugly source...) ==zatz
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:37:33 PDT