Rapid7 Advisory R7-0017: TCPDUMP ISAKMP payload handling denial-of-service vulnerabilities
CVE: CAN-2004-0183, CAN-2004-0184
March 30, 2004 - TCPDUMP v3.8.1 and earlier versions contain multiple flaws in the packet display functions for the ISAKMP protocol. Upon receiving specially crafted ISAKMP packets, TCPDUMP will try to read beyond the end of the packet capture buffer and crash.
- TCPDUMP v3.8.1 and earlier versions
The vendor was notified and they have released an updated version of TCPDUMP, version 3.8.2, which fixes these defects. Subsequently, the version number was bumped to 3.8.3 to match libpcap.
To test the security and robustness of IPSEC implementations from multiple vendors, the security research team at Rapid7 has designed the Striker ISAKMP Protocol Test Suite. Striker is an ISAKMP packet generation tool that automatically produces and sends invalid and/or atypical ISAKMP packets.
This advisory is the second in a series of vulnerability disclosures discovered with the Striker test suite. Striker will be made available to qualified IPSEC vendors. Please email email@example.com for more information on obtaining Striker.
There are two defects in the ISAKMP packet display functions in TCPDUMP. Both of them require that verbose packet display be enabled with the -v option. These defects result in out-of-bounds reads.
Overflow in ISAKMP Delete payload with large number of SPI's CVE ID: CAN-2004-0183
When displaying Delete payloads, TCPDUMP does not verify that (NSPIS * SPISIZE) fits within the snap buffer.
An ISAKMP packet with a malformed Delete payload having a large self-reported number of SPI's will cause TCPDUMP to crash as it tries to read from beyond the end of the snap buffer.
See section 3.15 of RFC 2408 for information on the Delete payload format.
Integer underflow in ISAKMP Identification payload CVE ID: CAN-2004-0184
An ISAKMP packet with a malformed Identification payload with a self-reported payload length that becomes less than 8 when its byte order is reversed will cause TCPDUMP to crash as it tries to read from beyond the end of the snap buffer. TCPDUMP must be using a snaplen of 325 or greater for this underflow to be triggered.
This is due to an inconsistency in the byte order conversion in the isakmp_id_print() function:
if (sizeof(*p) < id.h.len)
data = (u_char *)(p + 1);
data = NULL;
len = ntohs(id.h.len) - sizeof(*p);
If id.h.len is equal to, say, 256 (and this fits within the snap buffer), then len will be equal to:
ntohs(256) - sizeof(*p)
which becomes a negative value on i386.
Upgrade to version 3.8.3 of TCPDUMP. You should also consider upgrading to version 0.8.3 of libpcap. Note that many vendors package their own customized version of TCPDUMP and libpcap with their operating system distribution. You may want to consider contacting your operating system vendor for an upgrade.
Disclaimer & Copyright
Rapid7, LLC is not responsible for the misuse of the information provided in our security advisories. These advisories are a service to the professional security community. There are NO WARRANTIES with regard to this information. Any application or distribution of this information constitutes acceptance AS IS, at the user's own risk. This information is subject to change without notice.
This advisory Copyright (C) 2004 Rapid7, LLC. Permission is hereby granted to redistribute this advisory, providing that no changes are made and that the copyright notices and disclaimers remain intact.