SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   Application (Generic)  >   Tcpdump Vendors:   Tcpdump.org
Tcpdump l2tp_avp_print() Flaw May Let Remote Users Crash the System With Malformed L2TP Packets
SecurityTracker Alert ID:  1008748
SecurityTracker URL:  http://securitytracker.com/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.
Jan 17 2004 (Debian Issues Fix) Tcpdump l2tp_avp_print() Flaw May Let Remote Users Crash the System With Malformed L2TP Packets   (Matt Zimmerman <mdz@debian.org>)
Debian has released a fix.
Jan 19 2004 (EnGarde Issues Fix) Tcpdump l2tp_avp_print() Flaw May Let Remote Users Crash the System With Malformed L2TP Packets   (engarde-announce-admins@guardiandigital.com)
Guardian Digital has released a fix for EnGarde Secure Linux.
Jan 27 2004 (Mandrake Issues Fix) Tcpdump l2tp_avp_print() Flaw May Let Remote Users Crash the System With Malformed L2TP Packets   (Mandrake Linux Security Team <security@linux-mandrake.com>)
Mandrake has released a fix.



 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

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2014, SecurityGlobal.net LLC