Bug 81585

Summary:	CAN-2003-0093 tcpdump can crash a machine when it sees certain udp packets
Product:	[Retired] Red Hat Linux	Reporter:	Phil Meek <meekpn>
Component:	tcpdump	Assignee:	Harald Hoyer <harald>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	8.0	CC:	harrismc, k.georgiou, mitr, radu, samsonite451
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-04-24 14:52:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Phil Meek 2003-01-10 19:48:42 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

Description of problem:
When tcpdump sees a UDP packet from port 1646 (or any of the radius related
ports), it tries to decode the packet. If the data isn't really a radius packet,
then tcpdump cannot correctly decode it. While this is not always a problem, if
the second byte of data in the payload of the packet is a 0, which corresponds
to the length field of a radius header, tcpdump gets stuck in an infinite loop
that spews an infinte stream of "#0#0#0#0#0" until the process is killed. If
this information is being written to a file, then it quickly fills up the hard
drive, causing the machine to crash, effectively resulting in a denial of
service from a single packet.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Open up two windows.
2. Run the command "tcpdump -i lo 'udp port 1646'" in the first window.
3. Create a binary file with two bytes worth of zeros in it. I used "touch data"
and "hexedit data" to insert 00 00 into a file called data.
4. Run the command "nc -u -p 1646 127.0.0.1 1301 < data". The destination port
doesn't seem to matter very much, although there are probably some destination
ports which cause a different decoder to run.


Actual Results:  Window number one begins spewing the characters "#0#0#0#0#0" to
the screen. Not a big problem unless you happen to be storing this output in a
file, such as you would for an intrusion detection system. In this case, the
hard drive fills up and the system crashes.

Expected Results:  Tcpdump should have printed a nice simple message saying that
the packet could possibly be a radius packet and left it alone. At the very
least, it shouldn't get stuck in an infinte loop because they didn't check for zero.

Additional info:

The most recent code from the tcpdump.org website seems to fix the problem, but
management prefers rpm's to self-compiled code, and the most recent rpm versions
of tcpdump in 7.2, 7.3, and 8.0 all seem to be affected.

Comment 1 Harald Hoyer 2003-02-12 13:43:36 UTC

many thx... btw, 
$ nc -u -p 1646 127.0.0.1 1301 < /dev/zero
is a lot easier :)

--- tcpdump-3.6.2/print-radius.c.radlen 2003-02-12 14:38:32.000000000 +0100
+++ tcpdump-3.6.2/print-radius.c        2003-02-12 14:38:37.000000000 +0100
@@ -734,7 +734,7 @@
 {
    register const struct radius_attr *rad_attr = (struct radius_attr *)attr;

-   if (length < 3)
+   if (length < 3 || (rad_attr->len == 0))
    {
       printf(" [|radius]");
       return;

Comment 2 Mark J. Cox 2003-02-26 15:19:47 UTC

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2003-033.html

Comment 3 Mark J. Cox 2003-03-03 17:41:40 UTC

reopening, this shouldn't have got automatically closed as the errata for RHL
releases is still in the works, the above advisory only applies to Red Hat
Advanced Products users.

Comment 4 Sam 2003-03-08 04:18:12 UTC

Is there a technical reason why it's harder to patch the redhat 7.x and 8.0 than
advanced server, or do we get slower updates because we aren't paying for support?

Comment 5 Mark J. Cox 2003-03-19 15:56:59 UTC

*** Bug 86315 has been marked as a duplicate of this bug. ***

Comment 6 Mark J. Cox 2003-03-19 15:58:48 UTC

No, the two products have separate queues for errata and different priorities
placed on packages.  Over the last couple of weeks the priorities have been
placed on getting updated packages that solve critical security issues through
QA (such as Samba, kernel, etc)

Comment 7 Mike Harris 2003-03-19 16:12:57 UTC

from bug36815:
I would call blinding & crashing my Intrusion detection via denial of service a 
critical security issue.

any bug that causes endless loop hard disk writes that fill the file system 
tcpdump is logging to would be I hope a critical issue. 

my problem is that updated tcpdump and libpcap have been available from the 
source for days with no change to the packages available via RHN. 
Yes, I can update tcpdump from the sources at tcpdump.org but then after that 
tcpdump and libpcap will be excluded from automated rhn updates.

is there a way to bring a package back into up2date without backing out the 
tcpdump.org sources and reapplying via rhn

Comment 8 Mark J. Cox 2003-04-24 14:52:35 UTC

Was fixed by http://rhn.redhat.com/errata/RHSA-2003-032.html