Seg fault of tcpdump (v 3.8.1 and below) with malformed l2tp packets

[MH <procana () insight rr com>]

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