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:[EMAIL PROTECTED]
