RAZOR Home I think any time you expose vulnerabilities it's a good thing, - Attorney General Janet Reno Sponsored by BindView Razor HomeRazor Home Papers & AdvisoriesPapers & Advisories PresentationsPresentations ToolsTools Papers & Advisories Denial of Service in IPSEC implementations Issue Date: October 18, 2002 Contact: Todd Sabin CVE: CAN-2002-0666 Topic: Denial of Service in IPSEC implementations Overview: Some IPSEC implementations do not properly handle certain very short packets. Affected Systems: Linux w/ FreeSWAN FreeBSD 4.6 Note: FreeBSD's implementation apparently uses code from the KAME project (http://www.kame.net). Several other products also use KAME code and may be affected as well. Impact: Denial of Service FreeSWAN: kernel panic FreeBSD 4.6: kernel panic Details: IPSEC is a set of security extensions to IP which provide authentication and encryption. It includes specification for two types of packets, ESP and AH, using IP protocols 50 and 51, respectively. This advisory is based only on ESP on IPv4, but the same issues are likely be present in the AH and/or IPv6 cases, and implementors are advised to check those, when applicable. ESP (Encapsulating Security Payload) is the IPSEC protocol which provides packet level encryption. In most cases, it also includes some level of authentication. In this scenario, ESP packets look like this: +---------------------------+ | IP header (proto 50) | +---------------------------+ | SPI | 4 bytes +---------------------------+ | Sequence number | 4 bytes +---------------------------+ | ...data... | M bytes of payload +---------------------------+ | Auth data | N bytes, depending on algorithm +---------------------------+ SPI is a security parameter index, which, along with the IP destination address, identifies the SA (security assocation) to which this packet belongs. SAs (and their SPIs) are either created manually, or dynamically through key negotiation with ike/isakmp. The sequence number is a monotonically increasing number used to prevent replays. The size of the Auth data depends on the particular authentication algorithm used by the SA, but is usually at least 12 bytes. When such a packet arrives, the ipsec implementation looks up the relevant SA based on the SPI, checks the sequence number for replay, and then attempts to verify the authentication data is correct. There is a common error in ipsec implementations in that they either have no checks that such auth data is actually present, or that the checks are insufficient and/or incorrect. As a result, spoofing very short esp packets with known source, destination, SPI and high sequence number (only 8 bytes of IP payload) can cause a kernel panic. For illustration, here is the relevant code from the FreeBSD 4.6 implemenation, and why it is wrong. esp_input.c: esp4_input () Various code looking up the SA based on SPI and replay checking. Then, starting on line 219: { u_char sum0[AH_MAXSUMSIZE]; u_char sum[AH_MAXSUMSIZE]; const struct ah_algorithm *sumalgo; size_t siz; figure out how big the signature should be (siz) sumalgo = ah_algorithm_lookup(sav->alg_auth); if (!sumalgo) goto noreplaycheck; siz = (((*sumalgo->sumsiz)(sav) + 3) & ~(4 - 1)); if (AH_MAXSUMSIZE < siz) { ipseclog((LOG_DEBUG, "internal error: AH_MAXSUMSIZE must be larger than %lu\n", (u_long)siz)); ipsecstat.in_inval++; goto bad; } Next, it simply copies the number of bytes the signature should be from the end of the packet, without checking that such data exists. This is not actually fatal because if the signature isn't present, it will simply copy part of the IP header and then the authentication should fail later. m_copydata(m, m->m_pkthdr.len - siz, siz, &sum0[0]); Next it tries to verify the signature. 'off' was calculated earlier and is the offset into the packet that the esp data starts at. Assuming a 20 byte IP header, and ignoring any link-layer data, off will be 20. If we sent an esp packet with just an SPI and sequence number, m_pkthdr.len will be 28. If the authentication data is supposed to be 96 bits, size will be 12. Then, the calculation m->m_pkthdr.len - off - siz should be -4. However, 'siz' is of type size_t, which is unsigned, so (assuming 32bit ints) it's actually 4294967292 which is passed to esp_auth if (esp_auth(m, off, m->m_pkthdr.len - off - siz, sav, sum)) { ipseclog((LOG_WARNING, "auth fail in IPv4 ESP input: %s %s\n", ipsec4_logpacketstr(ip, spi), ipsec_logsastr(sav))); ipsecstat.in_espauthfail++; goto bad; } In esp_core.c: int esp_auth(m0, skip, length, sav, sum) struct mbuf *m0; size_t skip; /* offset to ESP header */ size_t length; /* payload length */ struct secasvar *sav; u_char *sum; 'length' is also of type size_t, so it's still 4294967292. There are some sanity checks, but they fail to catch this. /* sanity checks */ if (m0->m_pkthdr.len < skip) { ipseclog((LOG_DEBUG, "esp_auth: mbuf length < skip\n")); return EINVAL; } if (m0->m_pkthdr.len < skip + length) { ipseclog((LOG_DEBUG, "esp_auth: mbuf length < skip + length\n")); return EINVAL; } The second sanity check 'should' catch this, but doesn't, because the 'skip + length' expression is again unsigned, so we add 20 to 4294967292 and get 16. Subsequently, the code tries to checksum 'length' bytes of memory and causes a kernel panic. Much the same thing happens with the Free/SWAN code. There are other suspicious things in both code bases, as well. Neither implementation checks that the esp packet isn't totally empty before grabbing the spi from it, e.g. Workarounds: If your firewall is capable of filtering based on packet payload length, that may be an effective workaround. Recommendations: Install the appropriate patch from your vendor. References: CVE Name: CAN-2002-0666 CERT Vulnerability Note: http://www.kb.cert.org/vuls/id/459371 IPSEC RFCs: http://www.ietf.org/rfc/rfc2401.txt http://www.ietf.org/rfc/rfc2402.txt http://www.ietf.org/rfc/rfc2406.txt Contact: info@razor.bindview.com | Fax: 508-485-0737 | Bindview Home
[SECURITY] [DSA 201-1] New Free/SWan packages fix denial of service From: joey@infodrom.org (Martin Schulze) To: debian-security-announce@lists.debian.org (Debian Security Announcements) Date: Mon, 2 Dec 2002 16:22:12 +0100 (CET) Message was signed by Martin Schulze <joey@debian.org> (Key ID: 0x801EA932). The signature is valid, but the key's validity is unknown. -------------------------------------------------------------------------- Debian Security Advisory DSA 201-1 security@debian.org http://www.debian.org/security/ Martin Schulze December 2nd, 2002 http://www.debian.org/security/faq -------------------------------------------------------------------------- Package : freeswan Vulnerability : denial of service Problem-type : remore Debian-specific: no CERT advisory : VU#459371 Bindview discovered a problem in several IPSEC implementations that do not properly handle certain very short packets. IPSEC is a set of security extensions to IP which provide authentication and encryption. Free/SWan in Debain is affected by this and is said to cause a kernel panic. This problem has been fixed in version 1.96-1.4 for the current stable distribution (woody) and in version 1.99-1 for the unstable distribution (sid). The old stable distribution (potato) does not contain Free/SWan packages. We recommend that you upgrade your freeswan package. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody -------------------------------- Source archives: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4.dsc Size/MD5 checksum: 637 1917ba063e4058123034247ddb105bfa http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4.diff.gz Size/MD5 checksum: 322480 ad70a2ecd67bbc1ae7b6eb6fcdb84da8 http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96.orig.tar.gz Size/MD5 checksum: 2251757 9ea1a778713e48d39f3c77de5f54752b Architecture independent components: http://security.debian.org/pool/updates/main/f/freeswan/kernel-patch-freeswan_1.96-1.4_all.deb Size/MD5 checksum: 889918 30c73e274e84b62125136ec96160d23a Alpha architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_alpha.deb Size/MD5 checksum: 1761260 2463d0474314aa775126544baea6ec95 ARM architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_arm.deb Size/MD5 checksum: 1700504 f15929f25fb8bb953748edbe188511ba Intel IA-32 architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_i386.deb Size/MD5 checksum: 1678486 878523a3a03254bfa1e6a39052b50e1b Intel IA-64 architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_ia64.deb Size/MD5 checksum: 1861640 8a1a611c76cd023311bae7126dfa5b8a HP Precision architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_hppa.deb Size/MD5 checksum: 1723252 22df2896c7f4f96a693da436addc6d95 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_m68k.deb Size/MD5 checksum: 1660918 a55f47febd01eefd216e0da3b200de76 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_mips.deb Size/MD5 checksum: 1718046 e8fc45985fc4c25a2a9b9ab7d6e21e08 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_mipsel.deb Size/MD5 checksum: 1721266 c1bd4591da7f720d3fe7b4e134ac9f22 PowerPC architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_powerpc.deb Size/MD5 checksum: 1688682 0e1b5ce54d414da362c7eeda097acfa9 IBM S/390 architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_s390.deb Size/MD5 checksum: 1689648 fa2ac3caafbb37cbcde0138ba9b8f6c6 Sun Sparc architecture: http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_sparc.deb Size/MD5 checksum: 1706714 53ef4472274ffaac7e24455d9ec6c1a1 These files will probably be moved into the stable distribution on its next revision. Survey on the use of Debian GNU/Linux 2.2 alias potato: http://lists.debian.org/debian-devel-announce-0211/msg00001.html --------------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg> End of signed message -- To UNSUBSCRIBE, email to debian-security-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vulnerability Note VU#459371 Multiple IPsec implementations do not adequately validate authentication data Overview IPsec implementations from multiple vendors do not adequately validate the authentication data in IPsec packets, exposing vulnerable systems to a denial of service. I. Description For background: * RFC 2401 Security Architecture for the Internet Protocol * RFC 2402 IP Authentication Header * RFC 2406 IP Encapsulating Security Payload IPsec supports integrity and authentication for IP traffic by including a cryptographic checksum in each IPsec datagram. This authentication data is compared to the Integrity Check Value (ICV) that is calculated by the recipient. If the values match, the datagram is considered valid. BindView RAZOR has reported a vulnerability that exists in KAME (FreeBSD, NetBSD), FreeS/WAN (Linux), and possibly other IPsec implementations. While processing an IPsec datagram, vulnerable implementations do not properly calculate the length of the authentication data field for very small datagrams, resulting in an unsigned integer overflow. The ICV is then calculated for an overly large range of memory, which could cause a kernel panic on vulnerable systems. KAME, FreeBSD, and NetBSD are vulnerable due to the way they handle Encapsulating Security Payload (ESP) datagrams. II. Impact A remote attacker could crash a vulnerable system with a specially crafted IPsec packet. The attacker would need to supply the source and destination IP addresses, the Security Parameters Index (SPI), and a suitably large sequence number. All of this information is transmitted in plain text. III. Solution Upgrade or Apply a Patch Upgrade or apply a patch as specified by your vendor(s). Restrict Access When possible, restrict access to IPsec hosts and gateways. Note that this will not prevent attacks, it will only limit the number of potential sources. Systems Affected Vendor Status Date Updated Alcatel Not Vulnerable 15-Oct-2002 Apple Computer Inc. Vulnerable 15-Oct-2002 Avaya Unknown 22-Aug-2002 Borderware Not Vulnerable 18-Oct-2002 Cisco Systems Inc. Not Vulnerable 21-Oct-2002 Clavister Not Vulnerable 22-Aug-2002 Conectiva Unknown 29-Aug-2002 Cray Inc. Not Vulnerable 15-Oct-2002 Data General Unknown 29-Aug-2002 Debian Vulnerable 2-Dec-2002 eSoft Vulnerable 15-Oct-2002 Extreme Networks Unknown 15-Oct-2002 F-Secure Unknown 29-Aug-2002 FreeBSD Vulnerable 15-Oct-2002 FreeS/WAN Vulnerable 2-Dec-2002 Fujitsu Unknown 29-Aug-2002 Global Technology Associates Vulnerable 17-Oct-2002 Guardian Digital Inc. Unknown 29-Aug-2002 Hewlett-Packard Company Not Vulnerable 15-Oct-2002 Hitachi Not Vulnerable 15-Oct-2002 IBM Unknown 29-Aug-2002 Internet Initiative Japan Vulnerable 17-Oct-2002 Intoto Not Vulnerable 18-Oct-2002 Juniper Networks Unknown 29-Aug-2002 KAME Project Vulnerable 15-Oct-2002 Lucent Not Vulnerable 15-Oct-2002 MandrakeSoft Unknown 29-Aug-2002 Microsoft Corporation Not Vulnerable 17-Oct-2002 Montavista Not Vulnerable 21-Oct-2002 NEC Corporation Vulnerable 15-Oct-2002 NetBSD Vulnerable 22-Oct-2002 NetScreen Not Vulnerable 29-Aug-2002 Network Appliance Not Vulnerable 15-Oct-2002 Network Associates Unknown 29-Aug-2002 NeXT Unknown 29-Aug-2002 NIST Unknown 29-Aug-2002 Nortel Networks Unknown 29-Aug-2002 OpenBSD Unknown 29-Aug-2002 Openwall GNU/*/Linux Not Vulnerable 21-Oct-2002 PGP Unknown 29-Aug-2002 Red Hat Inc. Unknown 29-Aug-2002 SafeNet Not Vulnerable 15-Oct-2002 Sequent Unknown 29-Aug-2002 SGI Unknown 29-Aug-2002 Sony Corporation Unknown 29-Aug-2002 SSH Communications Security Unknown 29-Aug-2002 Sun Microsystems Inc. Not Vulnerable 29-Aug-2002 SuSE Inc. Unknown 29-Aug-2002 The SCO Group (SCO Linux) Unknown 29-Aug-2002 Unisys Unknown 29-Aug-2002 Wind River Systems Inc. Unknown 29-Aug-2002 References http://razor.bindview.com/publish/advisories/adv_ipsec.html http://www.ietf.org/rfc/rfc2401.txt http://www.ietf.org/rfc/rfc2402.txt http://www.ietf.org/rfc/rfc2406.txt Credit The CERT/CC thanks Todd Sabin of BindView RAZOR for discovering and reporting this issue. This document was written by Art Manion. Other Information Date Public 10/17/2002 Date First Published 10/17/2002 05:55:11 PM Date Last Updated 12/02/2002 CERT Advisory CVE Name CAN-2002-0666 Metric 5.14 Document Revision 24 If you have feedback, comments, or additional information about this vulnerability, please send us email.
*** Bug 11059 has been marked as a duplicate of this bug. ***
what about this issue ?
jhhudso: maybe you could help 2003-02-22 Super FreeS/WAN 1.99.5.1 is out.
someone should close this bug.
Closing as this was fixed a while ago and now is out-of-date.
