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.
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;
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
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)
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
Was fixed by http://rhn.redhat.com/errata/RHSA-2003-032.html