I just realized almost a week has passed since the T2 conference where more details about the elusive attack against the TCP/IP protocol were supposed to be presented, and we have yet to see any information we didn’t have before. Here is a quick summary of the information that is available now:

Robert Graham says that at least one of the attack vectors is tricking a machine into thinking it’s dealing with a very slow connection, keeping it open for years to send just a few bytes. This can completely starve the attacked machine of all resources:

[…] how we see the connection from the point of view of kernel resources. The socket, though, is probably closed. That’s the essence of this problem: closing the socket doesn’t necessarily free the connection resources if the connection is in a certain state.

I have a hard time believing this is the problem. Every TCP/IP stack that I know of implements timeouts for inactive connections; you might trick it into thinking the connection is still active by simulating a really slow connection, but if that is the problem it can be fixed quite easily by including the time the send buffer was last updated in the timeout calculation, and this won’t work at all if the attacking machine is no longer keeping the connection open. 

According to Heise, the attack can cause a system to go down in just five minutes. This was confirmed by a demonstration at T2; Ivan Krstić was at the conference and provides this eyewitness report from the demo:

This isn’t Yet Another Connection Flood or a SYN cookie problem. The demo brought a fully-patched XP machine to a complete freeze in about three minutes with only 30-40 (malicious) connections per second, and network utilization at the victim floating around 0.1% of 100Mbit/s.

That’s only about 7000 packets; unfortunately, there are no details to be found about what kind of “freeze” was witnessed. Was the CPU usage rising, or is the attack using all the memory in the machine? Even official responses from vendors provide no extra details, but they do say this is related to known weaknesses. That might point to this attack method: opening new connections so fast that the machine that is being attacked goes down from a lack of memory or other resources before timeouts kick in. That’s not new, and can be easily prevented in several ways. 

In addition to that, it has been confirmed by the Outpost24 researchers that first reported this that a TCP three-way handshake has to be completed before the attack can succeed, so it’s hard to spoof the origin of the attack. Anyone that is using this will be relatively easy to trace. 

For updates, check Fyodor’s excellent summary; and of course Lee’s response to that page.