In-Reply-To: <20031221174837.14808.qmail (at) sf-www3-symnsj.securityfocus (dot) com [email concealed]>

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 (at) securityfocus (dot) com [email concealed]; run by ezmlm

>Precedence: bulk

>List-Id: <bugtraq.list-id.securityfocus.com>

>List-Post: <mailto:bugtraq (at) securityfocus (dot) com [email concealed]>

>List-Help: <mailto:bugtraq-help (at) securityfocus (dot) com [email concealed]>

>List-Unsubscribe: <mailto:bugtraq-unsubscribe (at) securityfocus (dot) com [email concealed]>

>List-Subscribe: <mailto:bugtraq-subscribe (at) securityfocus (dot) com [email concealed]>

>Delivered-To: mailing list bugtraq (at) securityfocus (dot) com [email concealed]

>Delivered-To: moderator for bugtraq (at) securityfocus (dot) com [email concealed]

>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 (at) sf-www3-symnsj.securityfocus (dot) com [email concealed]>

>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 (at) yahoo (dot) com [email concealed]>

>To: bugtraq (at) securityfocus (dot) com [email concealed]

>Subject: Re: Remote crash in tcpdump from OpenBSD

>

>In-Reply-To: <3FE4CAC1.8010306 (at) freebsd.lublin (dot) pl [email concealed]>

>

>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

>

>

>

[ reply ]