Internet Security Systems - AlertCon(TM)

Timely Disclosure?

Posted by Mark Dowd on February 29, 2008 at 2:38 PM EST.

Several years ago, I discovered two vulnerabilities in the Solaris IP stack - specifically, in the processing of IP datagrams. Typically, vulnerabilities of this nature are quite serious, because the IP processing code has to be exposed to other untrusted machines, and any bugs in handling IP datagrams will result in serious firewall-related breaches, kernel panics, or worse. The bugs I discovered were no exception; here is a basic rundown:

Bug #1: Fragmentation Attack

This vulnerability was an interesting problem in the way that Solaris would handle IP fragment reassembly. Basically, for each fragment that arrived, the kernel would place the data portion of the fragment (that is, the data in the fragment but not the IP header) into a linked list for that particular datagram. When it received the first fragment for that queue, it would not strip out the IP header. Thus, when reassembly was complete, there would be a linked list where the first element contained the IP header and initial portion of data, and each subsequent member of the list contained additional portions of data. The problem was that when multiple fragments destined for the same queue had a particular bit clear, the reassembly algorithm would erroneously deem the queue to be complete when it wasn't. In fact, you could do this trick without ever sending the first (0-offset) fragment. What happens in this case is that the "IP Header" is retrieved from the first element in the linked list of fragments - which is a data portion of one of the fragments you sent! The result? Utilizing this trick would allow you to send several fragments that, when reassembled, would become an entirely different packet. You could send two TCP fragments that, when reassembled, would be interpreted as a UDP packet for example. This spells bad news for firewalls! Neat, huh?

Bug #2: Length Miscalculation

The second vulnerability occurred when determining the IP header length. Usually, to determine the IP header length, you take the first byte of the IP header, and mask off the lower 4 bits of the byte (the higher 4 bits are the IP version, version 4 in this case). Then, you multiply the lower 4 bits by 4, and that is the length of the IP header. The Solaris kernel would determine the size without masking off the lower 4 bits, and assuming that the IP version field was set to 4.

Now, obviously there was some validation to ensure that the IP version was indeed 4, and that the length field was at least 5. However, this validation was done very early in IP processing.  Using bug #1, it would be possible to circumvent this options length calculation, allowing you to specify a different version and length. This has several consequences; first of all, whenever any IP checksumming is done, it would be possible to cause a kernel panic, since the checksum algorithm would try to operate on out-of-bounds memory and eventually hit an unmapped page. Secondly, during IP options processing, it is possible to cause memory corruption, since several options (such as source routing) moves data around within the IP header. A dangerous bug, to be sure!

Anyway, why am I telling you this now, since I found these problems over 2 years ago? Well, when we originally disclosed these issues to Sun, they responded with a patch for the more serious issue (bug #2) fairly quickly and asked that we wait to report both bugs until they had released the patch for the second one, since they were somewhat related to one another.  Flash to two years later!  Sun releases the patch for the second issue.  At this point, the most serious issue has been patched for some time (Sun has released two newer versions of their operating system in the meantime), and we wouldn’t typically do an advisory on issue #1 alone. The first bug, while interesting and also a threat in terms of bypassing firewalls, offers an attacker a pretty limited scope for attack. So, the first bug can be used to widen your attack surface, but on its own cannot be used to compromise a host.

We do however recommend that you apply the patches that Sun have made available (http://sunsolve.sun.com/search/document.do?assetkey=1-66-200183-1).

Comments or opinions expressed on this Weblog are the opinions of the authors alone. They are not necessarily reviewed in advance by anyone but the individual authors, and neither IBM Internet Security Systems nor any other party necessarily agrees with them. The views expressed by outside contributors and links to outside websites do not represent the views of IBM Internet Security Systems, its management or employees. All content on this Weblog has been made available on an “as-is” basis, and IBM Internet Security Systems shall not be liable for any direct or indirect damages arising out of use of this Weblog.