Bug 81585 - CAN-2003-0093 tcpdump can crash a machine when it sees certain udp packets
Summary: CAN-2003-0093 tcpdump can crash a machine when it sees certain udp packets
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tcpdump
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
: 86315 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-10 19:48 UTC by Phil Meek
Modified: 2007-03-27 03:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-24 14:52:35 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:033 0 normal SHIPPED_LIVE Moderate: tcpdump security update 2003-01-29 05:00:00 UTC

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:

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 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 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]");

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.


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

Note You need to log in before you can comment on or make changes to this bug.