[12309] in bugtraq
Remote DoS in Axent's Raptor 6.0
daemon@ATHENA.MIT.EDU (Mike Frantzen)
Thu Oct 21 15:40:04 1999
Content-Type: text
Message-Id: <199910202245.RAA28104@expert.cc.purdue.edu>
Date: Wed, 20 Oct 1999 17:45:56 -0500
Reply-To: Mike Frantzen <frantzen@EXPERT.CC.PURDUE.EDU>
From: Mike Frantzen <frantzen@EXPERT.CC.PURDUE.EDU>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
This bug was discovered in the CERIAS lab's at Purdue by:
Florian Kerschbaum <fkerschbaum@cs.purdue.edu>
Mike Frantzen <frantzen@expert.cc.purdue.edu>
Thanks to the Purdue CERIAS Firewall group:
Stephanie Miller <millersa@cs.purdue.edu>
Florian Kerschbaum <fkerschbaum@cs.purdue.edu>
Mike Frantzen <frantzen@expert.cc.purdue.edu>
Eric Hlutke <eric@hlutke.com>
Hendry Lim <lim1@cs.purdue.edu)
Manu Pathak <pathakm@cs.purdue.edu>
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();
[.....]
