Tcpdump l2tp_avp_print() Flaw May Let Remote Users Crash the System With Malformed L2TP Packets
|
|
SecurityTracker Alert ID: 1008748
|
|
CVE Reference: CAN-2003-1029
(Links to External Site)
|
Date: Jan 17 2004
|
Impact: Denial of service via network
|
Fix Available: Yes
Vendor Confirmed: Yes
|
Version(s): 3.8.1 and prior versions
|
Description: A vulnerability was reported in tcpdump in the processing of L2TP packets. A remote user may be able to cause tcpdump to crash.
It is reported that there is a flaw in 'print-l2tp.c' that can be triggered by a remote user sending a bad length value in an L2TP
packet. The bug reportedly occurs in the l2tp_avp_print() function. A remote user can send a control packet without specifying
a length option to cause an infinite loop or potential crash.
Some demonstration exploit examples are provided:
perl -e 'print
.\x80\x02...\x00.x6 | nc -u 10.1.1.1 1701
perl -e 'print .\x80\x00...\x00.x6 . .\x01.' | nc -u 10.1.1.1 1701
|
Impact: A remote user can cause tcpdump to enter an infinite loop and potentially crash.
|
Solution: The vendor has issued a fix, available via CVS.
|
Vendor URL: www.tcpdump.org/ (Links to External Site)
|
Cause: Input validation error, State error
|
Underlying OS: Linux (Any), UNIX (Any)
|
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Fri, 16 Jan 2004 23:43:33 -0500
Subject: [tcpdump-workers] Seg fault of tcpdump (v 3.8.1 and below) with malformed
|
Subject: [tcpdump-workers] Seg fault of tcpdump (v 3.8.1 and below) with malformed l2tp
packets
From: MH <procana () insight ! rr ! com>
Date: 2003-12-24 15:20:44
The initial report came from Przemyslaw Frasunek regarding a crash of tcpdump
on OpenBSD with a malformed l2tp packet. However, I have found versions of tcpdump
up to 3.8.1 vulnerable to other malformed l2tp packets. The results range
from sending tcpdump into an infinite loop to forcing it to seg fault.
The issue is with the way the l2tp_avp_print() and print_octets() functions in
file print-l2tp.c handle input. In particular it seems this is in its handling of a bad
length value. Even if the control message packet does not specify a length
option (violation of RFC 2661) tcpdump will still try to interpret the length field
instead of raising an error/shunning due to this malformed packet. The seg fault
occurs when l2tp_avp_print() passes a bad length argument to print_octets() and sends
it looping until it segfaults.
The first test sent tcpdump into an infinite loop because the l2tp_avp_print()
function calls itself and passes bad data.
Test 1:
perl -e 'print .\x80\x02...\x00.x6 | nc -u 10.1.1.1 1701
The second test seg faulted tcpdump because l2tp_avp_print() passes bad data
to print_octets().
Test 2:
perl -e 'print .\x80\x00...\x00.x6 . .\x01.' | nc -u 10.1.1.1 1701
uP: i386
tcpdump: (up to 3.8.1)
libpcap: 0.7.2
os: Linux
I have not been able to seg fault tcpdump on OpenBSD. And, the infinite looping
does not occur on OpenBSD after applying Otto Moerbeek's patch.
Can anyone else reproduce these results?
Thanks,
Mike
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request@tcpdump.org?body=unsubscribe
|
|
