BugTraq
NetSky.q Virus. Looking for more detailed information on how the DOS will be performed. Mar 30 2004 06:18PM
Paul (paul edonkey2000 com) (1 replies)
Re: NetSky.q Virus. Looking for more detailed information on how the DOS will be performed. Mar 30 2004 10:03PM
Joe Stewart (jstewart lurhq com) (1 replies)
IPv4 fragmentation --> The Rose Attack Mar 31 2004 04:18AM
gandalf digital net (2 replies)
Re: IPv4 fragmentation --> The Rose Attack Apr 01 2004 12:07PM
Chris Brenton (cbrenton chrisbrenton org)
Re: IPv4 fragmentation --> The Rose Attack Mar 31 2004 08:07PM
stanislav shalunov (shalunov internet2 edu) (1 replies)
Re: IPv4 fragmentation --> The Rose Attack Mar 31 2004 11:42PM
Crist J. Clark (cristjc comcast net) (1 replies)
Re: IPv4 fragmentation --> The Rose Attack Apr 01 2004 02:21AM
stanislav shalunov (shalunov internet2 edu)
"Crist J. Clark" <cristjc (at) comcast (dot) net [email concealed]> 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/

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus