Fernando Gont wrote:

quoted text
> 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