This bug was discovered in the CERIAS lab's at Purdue by: Florian Kerschbaum <fkerschbaumat_private> Mike Frantzen <frantzenat_private> Thanks to the Purdue CERIAS Firewall group: Stephanie Miller <millersaat_private> Florian Kerschbaum <fkerschbaumat_private> Mike Frantzen <frantzenat_private> Eric Hlutke <ericat_private> Hendry Lim <lim1at_private) Manu Pathak <pathakmat_private> Environment: Sparc 5 85MHz Solaris 2.6 Generic_105181-12 Axent Raptor 6.0.0 Firewall Thesis: Axent's Raptor programmers have a switch statement for IP Options in a packet. They likely have cases for most of the options contained in the RFC's but only wrote handling code for the commonly 'malused' options (source routing). For all the other known options, they are handled by a generic routine which likely tries to skip that option. See probable code snapshot below. Background: IP Options are (generally) of the form: -------- -------- -------- -------- | Type | Length | ... | ... | -------- -------- -------- -------- Where the Type indicates which IP Option is present and the Length obviously indicates how long the option is. It also needs to be pointed out that there can be multiple options inside an IP packet -- they just follow each other. Problem: IP Packets are parsed either with interrupts masked off or while holding an vital global mutex. When the option parsing tries to skip a 'benign' option, it forgets to check if it is of zero length. So the end result is essentially: for (ecx = 20; ecx < header_length; ecx += 0 ) { ... } The Options that can lock up the firewall are the Timestamp option and the Security option. The copy bit does not appear to affect the results. Nor does the underlying protocol (TCP, UDP or random). Solution one: Learn to power cycle your firewall ;-) Solution two: Block all traffic with IP Options at your screening router. Solution three: Apply Axent's Hotfix ftp://ftp.raptor.com/patches/V6.0/6.02Patch/ Sidenote one: Axent received the bug and responded _swiftly_. I was extremely impressed. Sidenote two: Out of respect to the way Axent handled the bug (and the fact they are a CERIAS Sponsor), we are not releasing an exploit. This is the probable offending segment of code in Raptor. It is only an educated guess--I have not seen their code nor have I disassembled it. [.....] /* Parse the IP Options of the packet */ for (c = 20; c < (ip.ip_hl * 4); ) { switch ( packet[c] & ~COPY_BIT ) { case TIMESTAMP: case SECURITY: if ( c + 1 > ip.ip_hl * 4 ) goto done_parsing_label; option_length = packet[c + 1]; /* ****************************** **** * Forgetting to check if the option length is * zero here. So you enter an infinite loop * ****************************** ****/ if ( option_length + c > ip.ip_hl * 4 ) goto done_parsing_label; c += option_length; break; case END_OF_OPTIONS: goto done_parsing_label; case NOP: c++; break; case STRICT_SOURCE_ROUTE: case LOOSE_SOURCE_ROUTE: case RECORD_ROUTE: log_dangerous_packet(); default: if ( c + 1 >= ip.ip_hl * 4 ) goto done_parsing_label; option_length = packet[c + 1]; if ( (option_length == 0) ||(option_length + c >= ip.ip_hl * 4) ) goto done_parsing_label; c += option_length; break; } } done_parsing_label: queue_packet_down_stack(packet); unmask_interrupts(); [.....]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:16 PDT