96 lines
5.6 KiB
Plaintext
96 lines
5.6 KiB
Plaintext
Large Packet Attacks
|
|
(AKA Ping of Death)
|
|
---------------------------------
|
|
|
|
|
|
[ Introduction ]
|
|
|
|
Recently, the Internet has seen a large surge in denial of service
|
|
attacks. A denial of service attack in this case is simply an action of some
|
|
kind that prevents the normal functionality of the network. It denies service.
|
|
This trend began a few months back with TCP SYN flooding and continues with the
|
|
"large packet attack". In comparison with SYN flooding, the large packet attack
|
|
is a much more simple attack in both concept (explained below) and execution
|
|
(the attack can be carried out by anyone with access to a Windows 95 machine).
|
|
TCP SYN flooding is more complex in nature and does not exploit a flaw so much
|
|
as it exploits an implementation weakness.
|
|
The large packet attack is also much more devastating then TCP SYN
|
|
flooding. It can quite simply cause a machine to crash, whereas SYN flooding
|
|
may just deny access to mail or web services of a machine for the duration of
|
|
the attack. For more information on TCP SYN flooding see Phrack 49, article 13.
|
|
(NOTE: The large packet attack is somewhat misleadingly referred to as 'Ping of
|
|
Death` because it is often delivered as a ping packet. Ping is a program that
|
|
is used to test a machine for reachablity to see if it alive and accepting
|
|
network requests. Ping also happens to be a convenient way of sending the
|
|
large packet over to the target.)
|
|
The large packet attack has caused no end of problems to countless
|
|
machines across the Internet. Since its discovery, *dozens* of operating
|
|
system kernels have been found vulnerable, along with many routers, terminal
|
|
servers, X-terminals, printers, etc. Anything with a TCP/IP stack is in fact,
|
|
potentially vulnerable. The effects of the attack range from mild to
|
|
devastating. Some vulnerable machines will hang for a relatively short period
|
|
time then recover, some hang indefinitely, others dump core (writing a huge
|
|
file of current memory contents, often followed by a crash), some lose
|
|
all network connectivity, many rebooted or simply gave up the ghost.
|
|
|
|
[ Relevant IP Basics ]
|
|
|
|
Contrary to popular belief, the problem has nothing to do with the
|
|
`ping` program. The problem lies in the IP module. More specifically,
|
|
the problem lies the in the fragmentation/reassembly portion of the IP module.
|
|
This is portion of the IP protocol where the packets are broken into smaller
|
|
pieces for transit, and also where they are reassembled for processing. An IP
|
|
packet has a maximum size constrained by a 16-bit header field (a header is a
|
|
portion of a packet that contains information about the packet, including
|
|
where it came from and where it is going). The maximum size of an IP packet
|
|
is 65,535 (2^16-1) bytes. The IP header itself is usually 20 bytes so this
|
|
leaves us with 65,515 bytes to stuff our data into. The underlying link layer
|
|
(the link layer is the network logically under IP, often ethernet) can seldom
|
|
handle packets this large (ethernet for example, can only handle packets up to
|
|
1500 bytes in size). So, in order for the link layer to be able to digest a
|
|
large packet, the IP module must fragment (break down into smaller pieces)
|
|
each packet it sends to down to the link layer for transmission on the network.
|
|
Each individual fragment is a portion of the original packet, with its own
|
|
header containing information on exactly how the receiving end should put it
|
|
back together. This putting the individual packets back together is called
|
|
reassembly. When the receiving end has all of the fragments, it reassembles
|
|
them into the original IP packet, and then processes it.
|
|
|
|
[ The attack ]
|
|
|
|
The large packet attack is quite simple in concept. A malicious user
|
|
constructs a large packet and sends it off. If the destination host is
|
|
vulnerable, something bad happens (see above). The problem lies in the
|
|
reassembly of these large packets. Recall that we have 65,515 bytes of space
|
|
in which to stuff data into. As it happens, a few misbehaved applications
|
|
(and some specially crafted evil ones) will allow one to place slightly more
|
|
data into the payload (say 65,520 bytes). This, along with a 20 byte IP
|
|
header, violates the maximum packet size of 65,535 bytes. The IP module will
|
|
then simply break this oversized packet into fragments and eschew them to
|
|
their intended destination (target). The receiving host will queue all of the
|
|
fragments until the last one arrives, then begin the process of reassembly.
|
|
The problem will surface when the IP module finds that the packet is in
|
|
fact larger than the maximum allowable size as an internal buffer is
|
|
overflowed. This is where something bad happens (see above).
|
|
|
|
[ Vulnerability Testing and Patching ]
|
|
|
|
Testing to see if a network device is vulnerable is quite easy.
|
|
Windows NT and Windows 95 will allow construction of these oversized
|
|
packets without complaining. Simply type: `ping -l 65508 targethost`. In
|
|
this case, we are delivering an oversized IP packet inside of a ping packet,
|
|
which has a header size of 8 bytes. If you add up the totals, 20 bytes of IP
|
|
header + 8 bytes of ping header + 65,508 bytes of data, you get a 65,536 byte
|
|
IP packet. This is enough to cause affected systems to have problems.
|
|
Defense is preventative. The only way to really be safe from this
|
|
attack is to either ensure your system is patched, or unplug its network tap.
|
|
There are patches available for just about every vulnerable system. For
|
|
a copious list of vulnerable systems and patches, check out a 'Ping of Death'
|
|
webpage near you.
|
|
|
|
daemon9
|
|
Editor, Phrack Magazine
|
|
(daemon9@netcom.com)
|
|
|
|
|