Libreswan Denial of Service (multiple vulnerabilities)

Two Denial of Service vulnerabilities were found on May 15th, 2015 in the latest versions of Libreswan. These vulnerabilities have been assigned CVE-2015-3204 for reference. Libreswan has patched this vulnerability and released v3.13. I am releasing the exploit so that people will be able to test their servers. It is also easy to generate this exploit using the tools I am releasing today which found these two vulnerabilities and two vulnerabilities in strongSwan (Libreswan's competitor). If you have access to test equipment that runs an IPsec server, you should run this fuzzer against it. If you are a security researcher with any interest in IPsec, you should improve this fuzzer, find bugs with it, and send a patch.

Denial of Service in Libreswan jam_str

Product: Libreswan 3.12, 3.10, and possibly other versions
Website: https://libreswan.org/
Github: https://github.com/libreswan/libreswan
Type: Denial of Service (CWE-476)
Severity: Medium
CVSS Score: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C)

A single crafted UDP packet can crash pluto, the IKE daemon from Libreswan. The daemon asserts that the length of a string is greater than zero, which is not true. The impact of pluto daemon crashing is dependent on the environment and can vary quite greatly. Since IPsec is critical infrastructure, it should be considered of high importance.

Demo

The single packet which causes this DoS to occur is below split into structures:


b9ce3eefc8b661dd00000000000000000110020000000000000000580000003c
00000001ffffffff00000000010100010000002801010000800b0001000c00040001518080010007800e0100800300038002000280040005

Currently installed Libreswan:


[ebuild   R    ] net-misc/libreswan-3.10::gentoo  USE="pam -caps -curl -dnssec -ldap" 0 KiB

This configuration comes directly from the configuration howto on strongswan.org: https://www.strongswan.org/docs/readme4.htm#section_2.1

The Vulnerability

/*
 * Jam a string into a buffer of limited size.
 *
 * This does something like what people mistakenly think strncpy does
 * but the parameter order is like snprintf.
 * OpenBSD's strlcpy serves the same purpose.
 *
 * The buffer bound (size) must be greater than 0.
 * That allows a guarantee that the result is NUL-terminated.
 *
 * The result is a pointer:
 *   if the string fits, to the NUL at the end of the string in dest;
 *   if the string was truncated, to the roof of dest.
 *
 * Warning: Is it really wise to silently truncate?  Only the caller knows.
 * The caller SHOULD check by seeing if the result equals dest's roof.
 */
char *jam_str(char *dest, size_t size, const char *src)
{
	passert(size > 0);	/* need space for at least NUL */

	{
		size_t full_len = strlen(src);
		bool oflow = size - 1 < full_len;
		size_t copy_len = oflow ? size - 1 : full_len;

		memcpy(dest, src, copy_len);
		dest[copy_len] = '\0';
		return dest + copy_len + (oflow ? 1 : 0);
	}
}

[...]

/*
 * construct a string to name the bits on in a set
 *
 * Result of bitnamesof may be in STATIC buffer -- NOT RE-ENTRANT!
 * Note: prettypolicy depends on internal details of bitnamesofb.
 * binamesofb is re-entrant since the caller provides the buffer.
 */
const char *bitnamesofb(const char *const table[], lset_t val,
			char *b, size_t blen)
{
	char *const roof = b + blen;
	char *p = b;
	lset_t bit;
	const char *const *tp;

	passert(blen != 0); /* need room for NUL */

	/* if nothing gets filled in, default to "none" rather than "" */
	(void) jam_str(p, (size_t)(roof - p), "none");

	for (tp = table, bit = 01; val != 0; bit <<= 1) {
		if (val & bit) {
			const char *n = *tp;

			if (p != b)
				p = jam_str(p, (size_t)(roof - p), "+");

			if (n == NULL || *n == '\0') {
				/*
				 * No name for this bit, so use hex.
				 * if snprintf returns a different value from
				 * strlen, truncation happened
				 */
				(void)snprintf(p, (size_t)(roof - p),
					"0x%" PRIxLSET,
					bit);
				p += strlen(p);
			} else {
				p = jam_str(p, (size_t)(roof - p), n);
			}
			val -= bit;
		}
		/*
		 * Move on in the table, but not past end.
		 * This is a bit of a trick: while we are at stuck the end,
		 * the loop will print out the remaining bits in hex.
		 */
		if (*tp != NULL)
			tp++;
	}
	return b;
}

It isn't very clear what's going on just looking at the code, but you can see that p increases by strlen(p) or changes to what jam_str returns in two cases. jam_str always returns the input + copy_len or the input + copy_len + 1, which is derived from input. That means roof-p (which is size, the important variable in this vulnerability) should be decreasing steadily over this for loop. If a certain value is given, size is less than or equal to zero, giving us the passert crash.

Ironically, jam_str was designed to avoid common errors in strcpy and strncpy. Who would have thought that you would have serious issues when dealing with code this complex. No kidding.

Denial of Service in Libreswan process_packet_tail

A single crafted UDP packet can crash pluto, the IKE daemon from Libreswan. The daemon asserts that a pointer is not null, which is not true. The impact of pluto daemon crashing is dependent on the environment and can vary quite greatly. Since IPsec is critical infrastructure, it should be considered of high importance.

Demo

The single packet which causes this DoS to occur is below split into structures:


b9ce3eefc8b661dd00000000000000000f10020000000000000000580000003c
000000010000000100000030010100010000002801010000800b0001000c00040001518080010007800e0100800300038002000280040005

The Vulnerability

libreswan-3.12/include/ietf_constants.h:483:
	ISAKMP_NEXT_SAK = 15, /* SA KEK Payload - RFC 6407 */

libreswan-3.12/programs/pluto/ikev1.c:1851
				case ISAKMP_NEXT_SAK: /* AKA ISAKMP_NEXT_NATD_BADDRAFTS */
					loglog(RC_LOG_SERIOUS,
						"%smessage with unsupported payload ISAKMP_NEXT_SAK (as ISAKMP_NEXT_NATD_BADDRAFTS) ignored",
						excuse);
					break;

libreswan-3.12/programs/pluto/ikev1.c:1865
			passert(sd != NULL);

This branch does not set sd and does not return. Therefore the assertion is not true, crashing pluto with an abort.

What it means

When the IKE daemon crashes, it may or may not be restarted.
If it is restarted, it gives the attacker as many attempts as they want to get the IKE daemon into the startup state. Result: unknown.
If it is not restarted, the keys do not get changed. When the IV gets repeated, the stream loses some confidentiality and integrity. Replay becomes easy. Result: possible compromise.
If the system decides that the two systems should no longer use IPsec, the system may revert back to IP silently. Result: possible complete compromise.
If the system decides to instead stop sending packets to the affected system, this becomes a denial of service. Result: complete availability compromise.

The most likely result is clearly the availability compromise. However, it is possible for the system to revert to IP silently which is by far the worst possible case scenario. Ubuntu and Gentoo by default do not restart the server, which leads to availability compromise for those systems that do not have keys exchanged and for any system that has keys exchanged, it will lead to an unknown result. The worst possible result for Ubuntu and Gentoo in their default configuration is possible compromise. However, since IPsec requires administrators to configure their systems, it is likely that many different configurations exist that do not conform to these assumptions.

When encryption is compromised, the layer below becomes available to the attacker. IPsec was designed to run over public networks, thus attackers are there.

An aside about Man-in-the-middle attacks: Man-in-the-middle attacks are not theoretical. It is practical and exploitable on WiFi (road-warrior use-case), corporate networks (flat topology corporation use-case), server racks (DMZ/segmented use-case), and backbone routers (ISP use-case).

I am not trying to be alarmist. The odds of someone compromising your entire corporate network based on this vulnerability are low. The main reason to upgrade is because the attacker can deny availability to your IPsec server and the result of this attack is not fully understood for every environment.

Many thanks to Paul Wouters and the Libreswan team for a quick turnaround and a very well-informed discussion about the implications of these bugs. Their efforts ensured a smooth release of this information.

Conclusion

Two Denial of Service vulnerabilities were found on May 15th, 2015 in the latest versions of Libreswan. Exploits for these vulnerabilities are available. Upgrade as soon as possible. The most likely result of an attack is denial of service, but the result is dependent on the environment and can vary quite greatly. Since IPsec is critical infrastructure, it should be considered of high importance.

Libreswan Denial of Service (multiple vulnerabilities)

by Javantea

Research: May 15, 2015
Published: June 1, 2015

Introduction

Denial of Service in Libreswan jam_str

Demo

The Vulnerability

Denial of Service in Libreswan process_packet_tail

Demo

The Vulnerability

What it means

Conclusion