Re: TCP Resource Exhaustion Attacks

[Fyodor <fyodor () insecure org>]

On Fri, Oct 03, 2008 at 12:55:25PM +0100, Robert E. Lee wrote:
> Fyodor's post brought up a couple of well known availability attacks  
> with TCP.  At least he is contributing to the discussion.

I wasn't going to respond, since there is little point discussing your
TCP weaknesses if you won't disclose details.  However, your
sockstress slides from the SEC-T conference last month are now
available
(http://insecure.org/stf/tcpdos/outpost24-sect-sockstress.pdf) and
give us something concrete to discuss.

Slide 17 is titled "Full Connection Flood" and the slide says:

  Why Full Connection Flooding isn't more popular
    o A full connection requires attacker to consume state tracking
      resources too.

The netkill-style attacks I describe at
http://insecure.org/stf/tcp-dos-attack-explained.html don't require
tracking any state.  So how can you say that you knew and understood
the previous attacks, and then write something like this?

Also, Slide 18 is entitled "Defeating SYN Cookies" (even though it
doesn't defeat them, but that's a separate issue) and that slide plus
the next one say:

 - To defeat Server side SYN Cookies...
   - Employ Client side SYN Cookies
 - Start with a random 32-bit number
 - XOR this number against Client side of a connection attempt (192.168.1.3:51242)
 - Use output as ISN for SYN packets
 - When Client receives SYN/ACK's
   - (Sequence Number - 1) XOR'd with 32-bit number reveals the client
     sending IP and port
 - Client can now complete a full 3 way handshake without ever
   tracking anything in a table.

That adds extra complexity to the attack, but how is it in any way
useful?  You say that it "reveals the client sending IP and port", but
the client IP and port number are already in the normal TCP/IP header
fields of that same SYN/ACK packet.  A SYN/ACK is returned to the same
IP/port as the client which sent it, so you don't need to store that
data or do anything fancy.  It is in the destination IP field of the
IP header and the destination port in the TCP header.

Even if the four bytes you are squirreling away in the ISN were
essential, it seems like a stretch to describe that storage issue as
"why Full Connection Flooding isn't more popular".  You've mentioned
in the podcast that your attacks tend to require 10-40 packets per
second.  At four bytes stored per packet, that is up to 160 bytes per
second, or 14 megabytes per day-long attack.  My cell phone can easily
store that.  And if you need to send packets so quickly that the
required state is overwhelming, it isn't a low-bandwidth attack
anymore and you might as well be doing a simple packet flood instead.

> Fyodor's (and others) frustration I think is largely due to this  
> awkward partial discloser situation and the out of control barrage of  
> fear mongering we all just endured.

I agree, and I'm not really interested in a pissing contest of "who
discovered this first".  Particularly since I'm not even in the
running, as I acknowledge that the attacks I described have been
documented since 2000 or earlier.  And I'm sure that you and Jack have
extended the attack in clever ways.  The point I was trying to make is
just that I think it is better for researchers to "put up or shut up"
with these sorts of vulnerabilities.  If you had come out immediately
with full details, I would have saluted you.  Or if you had done a
quiet coordinated disclosure and then come out and announced it with
full details, I'd commend you just as strongly.  But this "out of
control barrage of fear mongering" you complain about seems to be a
direct and foreseeable consequence of your disclosure method.  If you
go interview with journalists all over the world and put out a press
release and conference presentations warning of a severe new attack,
and state that there are no known workarounds, and refuse to give
details because the flaw is too dangerous to even describe on the
Internet, this sort of fear-mongering will always ensue.

Also, I'm sorry if it sounds like I'm attacking you specifically, but
we've seen many cases of this "partial disclosure" nonsense lately,
and they all seem to lead to the "out of control barrage of fear
mongering" you describe.  So I finally decided to put my foot down and
have my say.  Even if nobody listens to me, I feel better for having
said it :).

I do agree with you that TCP implementations are far too vulnerable to
resource exhaustion attacks.  So while I don't agree with your
disclosure methods, I will be happy if your approach does lead to
making some TCP implementations more resilient.

Cheers,
-F

PS: The Dailydave mail which just went through was actually sent
    several days ago.  I guess Dave was too busy at BACon to check the
    moderation queue.

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org