5152043 2000-06-01  08:31  /135 rader/ Postmaster
Mottagare: Bugtraq (import) <11073>
Ärende: Jolt2 crashes tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: multipart/alternative 
             boundary="----=_NextPart_000_01BE_01BFCA26.AB0D3240"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <01c101bfca50$9481eb40$8d20fea9@cisco.com>
Date:         Tue, 30 May 2000 11:03:21 -0500
Reply-To: "Earl T. Carter" <ecarter@CISCO.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Earl T. Carter" <ecarter@CISCO.COM>
X-To:         bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_01BE_01BFCA26.AB0D3240
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I was testing the effects of jolt2 on a Win2K system in our lab.  The
= command line options were:

    jolt2 x.y.z.q

As advertised, this caused the win2K to freeze.  At the same time, I was =
watching the network traffic on a Redhat Linux 6.0 system using tcpdump. =
 After I killed the Jolt2 process, the Win2K box was back to normal,
but = the Linux box was completely locked up.  The Linux machine
required a = hard reset to get it operational again.  The command
that I used on the = tcpdump command line was:

    tcpdump -n -s 1500 -w /tmp/filename

After some quick testing, I discovered that the Linux box would not
lock = up if the network traffic is output to the screen.  I also
discovered = that using the default snaplen and writing to a file
does not cause a = problem.  The lock up seems to only occur when you
specify a snaplen of = 1500 (entire Ethernet packet) and use
Tcpdump's=20 "-w" command to write the sniffed packets to a file.  It
only takes = about 5 seconds worth of jolt2 traffic to cause the
Linux box to lock = up.

The same problem appears on the latest version of tcpdump (3.4.a6).
I = have not tested the latest Alpha version (3.5), nor have I tested
any = other versions of tcpdump other than the two that I have
listed.  If I = find out any more information in my further testing,
I will forward it = on to the bugtraq mailing list.

P.S. I am sending this to the bugtraq mailing list, since I do not
know = who is in charge of updates to the Tcpdump Software.

Earl Carter
Security Research Engineer

ecarter@cisco.com

------=_NextPart_000_01BE_01BFCA26.AB0D3240
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I was testing the effects of jolt2 on a =
Win2K=20
system in our lab.  The command line options were:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>    jolt2 =
x.y.z.q</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>As advertised, this caused the win2K to =

freeze.  At the same time, I was watching the network traffic on a =
Redhat=20
Linux 6.0 system using tcpdump.  After I killed the Jolt2 process, =
the=20
Win2K box was back to normal, but the Linux box was completely locked =
up. =20
The Linux machine required a hard reset to get it operational =
again.  The=20
command that I used on the tcpdump command line was:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>    tcpdump -n -s 1500 =
-w=20
/tmp/filename</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>After some quick testing, I discovered =
that the=20
Linux box would not lock up if the network traffic is output to the=20
screen.  I also discovered that using the default snaplen and =
writing to a=20
file does not cause a problem.  The lock up seems to only occur =
when you=20
specify a snaplen of 1500 (entire Ethernet packet) and use Tcpdump's=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"-w" command to write the sniffed =
packets to a=20
file.  It only takes about 5 seconds worth of jolt2 traffic to =
cause the=20
Linux box to lock up.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>The same problem appears on the latest =
version of=20
tcpdump (3.4.a6).  I have not tested the latest Alpha version =
(3.5),=20
nor have I tested any other versions of tcpdump other than the two that =
I have=20
listed.  If I find out any more information in my further testing, =
I will=20
forward it on to the bugtraq mailing list.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>P.S. I am sending this to the bugtraq =
mailing list,=20
since I do not know who is in charge of updates to the Tcpdump=20
Software.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Earl Carter</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Security Research Engineer</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:ecarter@cisco.com">ecarter@cisco.com</A></FONT></DIV></BOD=
Y></HTML>

------=_NextPart_000_01BE_01BFCA26.AB0D3240--
(5152043) ------------------------------------------(Ombruten)