Kill’em all TCP DoS
Last week a new hot topic arose in many security related blogs, podcasts and forums. A “new” and “devastating” DoS attack against TCP was revealed in a interview to two security researchers, Jack C. Louis and Robert E. Lee, both of them from Outpost24, who talked about their research in this podcast.
OK, a new “massive-destruction-bug”, one more to the list… do you remember when I wrote about the OpenSSL, BGP and DNS bugs? (in spanish).
The technical details that they have released are few and ambiguous, there were some confusion in many forums where people thought that it was a problem related with the Syn Cookies implementation, but it isn’t. They talked about Syn Cookies not in the server side but in the client side, as a way to establish a lot of connections without exhausting local resources.
Where’s the problem then? seemingly they were performing a massive scan and pentesting work with their UnicornScan tool when they found out that several hosts stuck, hanged even rebooted after the TCP connection was established in several “creative ways”.
Mainly it seems that one of those “creative ways” is the use a TCP window of 0, this means from the server point of view, that the client hasn’t enough resources (buffers) to receive data so the server waits until the retry timeout finish, send an ACK TCP segment to the client and waits for the answer to check if the window has been increased, in other words, if the client has now buffers to receive data.
It seems that if you establish several connections to a server that have an open TCP port, set a window of 0 in the initial negotiation during the three-way-handshake, and always answer to the ACK of the server with a window of 0, the server may end up using all the available resources, or maybe is just a matter of filling up the established connection table with never ending connections due to the 0 size TCP window.
From the client side, this work can be done with a minimum resource consumption as the connections are established through a TCP/IP stack in userland, and not the kernel one, here is when sockstress tool do the trick, besides that very few packets/bandwidth are needed to force the server to go to this state.
Maybe the problem is related to huge timeouts when a connection is in TIME_WAIT state, or with SACK before FIN state… Well I don’t know, there’re a lot of strange combinations that can end in a closed socket but with the related resources not correctly freed.
Neither a detailed technical explanation nor the sockstress tool has been released yet, so this is only a personal interpretation of what I have readed and listened. I guess that we’ll have to wait one more week to T2 Conference to learn more about all this mother-of-all-DoS thing. Some people is a bit skeptical about all this thing, just have to read Fyodor’s great post about all this topic.
Even though researchers assert that all network stacks (Windows, Linux, Solaris) are vulnerable to this bad client behaviour, no attack has been publicly reported to date. Hype? marketing to attract people to the conference? We’ll see in a week.
Comments
Leave a Reply