Red Hat Bugzilla – Bug 81585
CAN-2003-0093 tcpdump can crash a machine when it sees certain udp packets
Last modified: 2007-03-26 23:59:54 EDT
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):
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.
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.
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))
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.
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.
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?
*** Bug 86315 has been marked as a duplicate of this bug. ***
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)
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
Was fixed by http://rhn.redhat.com/errata/RHSA-2003-032.html