bugtraq - Re: IPv4 fragmentation --> The Rose Attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86zn9wl9os.fsf@abel.internet2.edu>
Date: 31 Mar 2004 21:21:39 -0500
From: stanislav shalunov <shalunov@...ernet2.edu>
To: cjclark@...m.mit.edu
Cc: bugtraq@...urityfocus.com
Subject: Re: IPv4 fragmentation  --> The Rose Attack

"Crist J. Clark" <cristjc@...cast.net> writes:

> IPv6 does have end-station fragmentation, and therefore, it DOES have
> reassebly, see Section 4.5 of RFC2460. I do not see why an IPv6
> implementation would not also potentially be affected.

You're correct.  IPv6 is affected as well.

> This is YANFA, Yet Another IP Fragmentation Attack. Teardrop, Ping O'
> Death, NewTear, Boink, yada-yada. Some have exploited bugs in
> reassembly code (over lapping frags, >65535-byte packets, etc.) and
> others, like this, are flat out resource exhaustion DoSes.

What you list above is, to an extent, different from this attack.
While with teardrop et al. a specific bug is exploited and it is quite
clear how to fix the bug so that the attack no longer works, this
attack stems from the very requirement to reassemble packets.  For
IPv6, one is to keep fragments for 60 seconds.  For IPv4, there's no
specific timeout, but 15 to 255 seconds are mentioned.

In other words, regardless of IP version, this technique allows an
attacker to lock tens of kilobytes of kernel memory for tens of
seconds by sending two small packets.

This is an order to two orders of magnitude less powerful than
TCP-based attacks that allow an attacker to lock tens of kilobytes of
kernel memory for tens of minutes by sending two small packets.

With TCP-based attacks, a DSL user can use up all memory of a server [1].

With this, more than T1 worth of capacity is required to keep a
server's memory locked up.

> The IP stack needs to be sane about how many datagrams it will try to
> reassemble at once.

Using a direct memory limit would seem a preferable strategy (combined
with using data structures that don't need to allocate 64kB just to
hold two tiny fragments).

[1] Assume 128B for two packets, 128kb/s uplink, 64kB TCP window size
    on the server, and 500-second timeout; then we have 125 hits per
    second, taking out 64kB each for 500s.  That's 4GB of kernel
    memory on the server.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/