By Dr.
InfoComm Security/QA, Computer Centre
National University of Singapore
01, Apr, 2004

Introduction

Teardrop, Ping O' Death, NewTear… While some of us are thinking that fragmentation attacks are out-dated, here comes a new type of it. It is reported to Bugtraq by Ken Hollis on 31/March/04 and named Rose Attack.

The attack is very simple, which involves only two fragmented packets being sent to the victim machine. The first packet, which is of the size of 32 bytes, is the initial offset zero fragment. The second, also of the size of 32 bytes, is set to an offset of 64800 bytes into the datagram. When the two packets are sent out, the victim machine’s CPU cannot process fragmented packets until the queue for the fragments times out, thus causing DOS attack.

Interesting Points of the Attack

There are three interesting points worth noticing regarding this attack:

• It does not require a response from the target system. Thus the source IP address can be spoofed, making tracing of attacker difficult if not impossible.
• It does not matter whether the fragmentation packets are of TCP, UDP or ICMP type. The attack in on layer there, the IP layer, hence it may affect all IP devices.
• The attack is very simple.

Due to these characteristics, the attack may pose considerable threats to the internet today if no action is taken promptly.

Solution

The problem has been reported to vendors before it is published on Bugtraq. No announcement has been made by any vendor regarding it. Several recommendations have been proposed on Bugtraq so far:

• Do not reassemble the fragments until all have been received. Just save the fragments, look at the size of all the fragments received and when the fragments total the size of the anticipated packet then take the CPU time to reassemble them in the correct order. If you never get all the "middle" fragments then you never waste CPU trying to create a buffer the size of the fragment and CPU time trying to reorder them correctly. If while reassembling the packet *any* of the packet is incorrect (teardrop attack, etc.) just drop the packet. Don't waste any more CPU time.
• Alternately you could just create 200 buffers (with a binary tree lookup, a fast lookup) that are the maximum size a packet could be at startup (i.e. 200 64k buffers, about 12Mb total of memory). Put the fragment in the correct place and use a FIFO type buffer. If a fragmented packet does not get completed before there are over 200 fragments, and a new fragmented packet arrives then the "oldest" fragmented packet gets dumped.

Let’s monitor Bugtraq closely for any update on this matter.