Fernando Gont wrote:
At 01:56 p.m. 01/10/2008, Peter J. Philipp wrote:
I listened to the podcast and got the idea that the socket is in
ESTABLISHED state (so after 3 way handshake) and they
mention that a packets PCB resources have timers, and that is what
they exploit.
That was just an example of the type of resources that could be
exhausted.
Perhaps you establish the session and
send an HTTP request (pretend it's http) and never ACK the answer
that gets repeated based on the internal timers. It seemed to me
they say that some stop repeating their content and just die.
That would be Shalunov's netkill attack, which aims at exhausting
memory by tying it to both PCBs and socket send buffers.
I looked this up on google, the URL for this attack is here:
http://shlang.com/netkill/ , I noticed it was a little bit
different from what I described because the state is in the FIN_WAIT_1
state on the remote machine, the TCP state
diagram in RFC 793 page 23 shows that a FIN is sent from the client's
close() to the server to reach that state, so it differs. If you have
a userland TCP/IP stack you can cease communication without the FIN
being sent.
I listened to the interview's first 5 minutes again and they mention
their own TCP/IP stack and that it was quite fast giving them a large
window; so large window, established state and userland TCP/IP stack is
their formula.
Here is the URL for the interview again the first 5 minutes are in
swedish so one can skip them:
mplayer -ss 5:0 http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3
If the discoverers of this bug don't make their sockstress available to
OpenBSD then I have a userland TCP/IP stack for OpenBSD developers (mail
me), but it's only written to be a server, but I suspect it would be
easy to make it a client, just have to dust it off from my CVS as it's
quite old (2004 possibly).
Regards,
-p
