The Internet is now the world's most popular network and it is full of potential vulnerabilities. In this series of articles, we explore the vulnerabilities of the Internet and what you can do to mitigate them.
Packet fragmentation is the part of the Internet Protocol (IP) suite of networking protocols that assures that IP datagrams can flow through any other sort of network. (rfc791) Fragmentation works by allowing datagrams created as a single packet to be split into many smaller packets for transmission and reassembled at the receiving host.
Packet fragmentation is necessary because underlying the IP protocol, other physical and or logical protocols are used to transport packets through networks. A good example of this phenomena is on the difference between Ethernet packets (which are limited to 1500 bytes), ATM packets (which are limited to 56 bytes), and IP packets which have variable sizes up to about 1/2 million bytes in length.
The only exception to this rule is in the case of an internet datagram marked don't fragment . Any internet datagram marked in this way is supposed to not be fragmented under any circumstances. If internet datagrams marked don't fragment cannot be delivered to their destination without being fragmented, they are supposed to be discarded instead. Of course, this rule doesn't have to be obeyed by the IP software actually processing packets, but it is supposed to be.
The packet fragmentation mechanism leads to attacks that bypass many current Internet firewalls, but the reason these attacks work is not because of the way fragmentation is done, but rather because of the way datagrams are reassembled.
Datagrams are supposed to be fragmented into packets that leave the header portion of the packet intact except for the modification of the fragmented packet bit and the filling in of an offset field in the IP header that indicates at which byte in the whole datagram the current packet is supposed to start. In reassembly, the IP reassembler creates a temporary packet with the fragmented part of the datagram in place and adds incoming fragments by placing their data fields at the specified offsets within the datagram being reassembled. Once the whole datagram is reassembled, it is processed as if it came in as a single packet.
According to the IP specification, fragmented packets are to be reassembled at the receiving host. This presumably means that they are not supposed to be reassembled at intermediate sites such as firewalls or routers. This decision was made presumably to prevent repeated reassembly and refragmentation in intermediate networks. When routers and firewalls followed the rules, they found a peculiar problem.
The way firewalls and routers block specific services (such as telnet ) while allowing other services (such as the world wide web http service) is by looking into the IP packet to determine which Transfer Control Protocol (TCP) port is being used. If the port corresponds to 80, the datagram is destined for http service, while port 23 is used for telnet . In normal datagrams, this works fine. But suppose we didn't follow the rules for fragmentation and created improper fragmented packets? Here's what one attacker did:
Like many Internet services, the underlying programs in the destination host assumes that the incoming data is in the proper format and was created by a legitimate source. This situation is a corollary to:
Computers can't tell the difference between the truth and a lie, and neither can many humans. But unlike most humans, in the case of most modern computers, even the simplest of lies work, and the same lie works again and again until the computer is fixed. Then another lie will probably work.
In this case, the attacker lies about the port this datagram is destined for, and the packet filters and firewalls believe the lie.
Since a datagram can be made to pass where it is not supposed to go, it may be able to enter a trusted network and act as if it were a trusted datagram. This can be exploited to corrupt information. If the firewall can be fooled into allowing ICMP or similar packets to pass, this mechanism can also be used to deny services.
Once an attacker has entered the host under attack, the same mechanism may be planted in that host to send outbound packets past the firewall even though they are not supposed to be passed. Thus it can be used to leak confidential information as well.
Except in the rarest of circumstances, you cannot refuse to allow fragmentation without hopelessly crippling your networking capability. Therefore, you have to live with it. The question is how? Here are some things other people have done:
The fragmentation and reassembly of packets is one example of why each host is potentially responsible for its own protection. Just because you have a firewall, doesn't mean you can be lax about host protection.
If your vendor has an update to cover fragmentation and it doesn't leave a denial of services attack uncovered, by all means get the update. But always remember that no defense is perfect. Use defense-in-depth for increased assurance.
This paper presents a somewhat abstracted view of the fragmentation attack. A fully detailed account is a bit too complex for this forum and, frankly, adds little to understanding the issue at this level.