FIPS mode assertion failure via malicious CERT payload

Libreswan contains a reachable assertion in the X.509 certificate processing path when operating in FIPS mode. After calling CERTExtractPublicKey(), the returned public key is asserted to be non-NULL, although the function may legitimately return NULL if public key extraction fails (for example, when processing a certificate with an RSA exponent of zero). An unauthenticated remote attacker can send a specially crafted CERT payload during an IKEv1 or IKEv2 exchange to trigger the assertion and terminate the daemon, resulting in a denial of service. The issue is only reachable when Libreswan is running in FIPS mode and certificate-based authentication is in use with at least one CA certificate loaded in the Libreswan NSS database; deployments using only Pre-Shared Key (PSK) authentication without loaded CA certificates are not affected.

An invalidly formatted IKEv2 fragment causes the Libreswan pluto daemon to crash and restart. Continued exploitation would cause a denial of service. The function reassemblev2incomingfragments() would ignore unknown outer payloads but still store these in a fixed size array msgdigest.digest[PAYLIMIT]. An off-by-one error in the assertion PASSERT(logger, md->digestroof < elemsof(md->digest)) causes the daemon to abort. No remote code execution is possible. Any configuration that allows IKEv2 connections that do not set fragmentation=no are vulnerable. IKEv1 is not affected.

IKEv1 Denial of Service via RSA-SHA1 (PKCS#1 Version 1.5 Encrypted) authentication payload

IKEv2 Denial of Service via RSA-SHA1 (PKCS#1 RSASSA-PKCS1-v15) authentication payload

A security issue in NM-libreswan, where we fail to sanitize the VPN configuration from a local unprivileged user and pass it directly to Libreswan.

The libreswan connection configuration is simple key=value format, but we fail to check for or escape special characters, including newlines, which makes it possible for the user to trick us to treat values as key.

Unfortunately, there's one particular key that takes an executable command as an argument: leftupdown (couldn't find more in ipsec.conf(5)). We normally use it to specify the NM-libreswan callback, that would pass L3 configuration back to NM. It can be abused to execute arbitrary code.

IKEv1 default AH/ESP responder can cause libreswan to abort and restart

An issue was discovered in Libreswan before 4.12. When an IKEv2 Child SA REKEY packet contains an invalid IPsec protocol ID number of 0 or 1 an error notify INVALIDSPI is sent back. The notify payload's protocol ID is copied from the incoming packet but the code that verifies outgoing packets fails an assertion that the protocol ID must be ESP (2) or AH(3) and causes the pluto daemon to crash and restart. NOTE: the earliest affected version is 3.20.

An issue was discovered in Libreswan 3.x and 4.x before 4.12. When an IKEv1 ISAKMP SA Informational Exchange packet contains a Delete/Notify payload followed by further Notifies that act on the ISAKMP SA such as a duplicated Delete/Notify message a NULL pointer dereference on the deleted state causes the pluto daemon to crash and restart.

An issue was discovered in Libreswan before 4.12. When an IKEv1 Quick Mode connection configured with IDIPV4ADDR or IDIPV6ADDR receives an IDcr payload with IDFQDN a NULL pointer dereference causes a crash and restart of the pluto daemon. NOTE: the earliest affected version is 4.6.

A vulnerability was found in the libreswan library. This security issue occurs when an IKEv1 Aggressive Mode packet is received with only unacceptable crypto algorithms, and the response packet is not sent with a zero responder SPI. When a subsequent packet is received where the sender reuses the libreswan responder SPI as its own initiator SPI, the pluto daemon state machine crashes. No remote code execution is possible. This CVE exists because of a CVE-2023-30570 security regression for libreswan package in Red Hat Enterprise Linux 8.8 and Red Hat Enterprise Linux 9.2.

pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. The earliest affected version is 3.28.

When an IKEv1 Aggressive Mode packet is received with only unacceptable crypto algorithms, the response packet is not sent with a zero responder SPI. When a subsequent packet is received where the sender re-uses the libreswan responder SPI as its own initiator SPI, the pluto daemon state machine crashes. No remote code execution is possible.

https://github.com/libreswan/libreswan/issues/1039

A crafted TS payload with an incorrect selector length may allow a remote attacker to cause a denial of service.

Libreswan 4.2 through 4.5 allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted IKEv1 packet because pluto/ikev1.c wrongly expects that a state object exists. This is fixed in 4.6.

An out-of-bounds buffer read flaw was found in the pluto daemon of libreswan from versions 3.27 till 3.31 where, an unauthenticated attacker could use this flaw to crash libreswan by sending specially-crafted IKEv1 Informational Exchange packets. The daemon respawns after the crash.

The Libreswan Project has found a vulnerability in the processing of IKEv1 informational exchange packets which are encrypted and integrity protected using the established IKE SA encryption and integrity keys, but as a receiver, the integrity check value was not verified.

Bugzilla issue:

https://bugzilla.redhat.com/showbug.cgi?id=1713512

In Libreswan 3.27 an assertion failure can lead to a pluto IKE daemon restart. An attacker can trigger a NULL pointer dereference by initiating an IKEv2 IKESAINIT exchange, followed by a bogus INFORMATIONAL exchange instead of the normallly expected IKEAUTH exchange. This affects sendv2Nspiresponsefromstate() in programs/pluto/ikev2send.c that will then trigger a NULL pointer dereference leading to a restart of libreswan.

A vulnerability was found in libreswan 3.17. IKEv2 bogus proposal lacking DH transform causes pluto daemon to restart.

A vulnerability was found in libreswan 3.17. IKEv2 bogus proposal lacking DH transform causes pluto daemon to restart.

programs/pluto/ikev1.c in libreswan before 3.17 retransmits in initial-responder states, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed UDP packet. NOTE: the original behavior complies with the IKEv1 protocol, but has a required security update from the libreswan vendor; as of 2016-06-10, it is expected that several other IKEv1 implementations will have vendor-required security updates, with separate CVE IDs assigned to each.

Libreswan 3.16 might allow remote attackers to cause a denial of service (daemon restart) via an IKEv2 aesxcbc transform.

The pluto IKE daemon in libreswan before 3.15 and Openswan before 2.6.45, when built with NSS, allows remote attackers to cause a denial of service (assertion failure and daemon restart) via a zero DH g^x value in a KE payload in a IKE packet.

libreswan 3.9 through 3.12 allows remote attackers to cause a denial of service (daemon restart) via an IKEv1 packet with (1) unassigned bits set in the IPSEC DOI value or (2) the next payload value set to ISAKMPNEXTSAK.

Libreswan 3.7 and earlier allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads.

The ikev2parentinI1outR1 function in pluto/ikev2parent.c in libreswan before 3.7 allows remote attackers to cause a denial of service (restart) via an IKEv2 I1 notification without a KE payload.

Race condition in the libreswan.spec files for Red Hat Enterprise Linux (RHEL) and Fedora packages in libreswan 3.6 has unspecified impact and attack vectors, involving the /var/tmp/libreswan-nss-pwd temporary file.

Libreswan 3.6 allows remote attackers to cause a denial of service (crash) via a small length value and (1) no version or (2) an invalid major number in an IKE packet.

Buffer overflow in the atodn function in libreswan 3.0 and 3.1, when Opportunistic Encryption is enabled and an RSA key is being used, allows remote attackers to cause a denial of service (pluto IKE daemon crash) and possibly execute arbitrary code via crafted DNS TXT records. NOTE: this might be the same vulnerability as CVE-2013-2053 and CVE-2013-2054.

Paul Wouters reports:

An audit of code from The Libreswan Project revealed a remote buffer overflow in the atodn() function used by both libreswan, openswan, and older versions of strongswan and superfreeswan when called from atoid()

Vulnerable versions: Openswan versions 1.x to 2.6.38

Vulnerability information: When enabling Opportunistic Encryption ("OE") using oe=yes (default is 'no') the IKE daemon pluto requests DNS TXT records to obtain public RSA keys of itself and its peers. These records can contain an IPsec gateway specification containing an fully qualified hostname which is passed to a function atoid().

When X.509 support was added to FreeS/WAN, ASN.1 parsing was added to the function atoid() which converts an ASCII ID representation into an internal struct id representation using a static buffer via the function temporarycyclicbuffer()

While DNS TXT records cannot contain ASN.1 representations, the code mistakenly checked for such interpretation if the DNS TXT FQDN contained an '=' symbol. Since DNS TXT buffers can be larger than what the ASN.1 parsing code expected, parsing such a record can trigger a buffer overflow leading to remote execution of code, specifically when overflowing into the struct kernelops which is a table of function pointers.

Exploitation: This exploit can only be triggered when the ipsec.conf configuration file enables Opportunistic Encryption via the option 'oe=yes'. If this option is not present, it defaults to 'no'.

Configurations that enable "OE" without preconfiguring their own public RSA key in DNS will be under severe connectivity problems leaving the machine with 30 second delay for each outgoing connection - a deployment scenario that is extremely unlikely to appear in the wild.

In the unlikely event that machines are configured as such, this vulnerability can only be exploited by a remote attacker controlling the reverse DNS entry for the IP address of the targetted host. If the machine is properly configured for OE, an attacker only needs to trigger a connection to an IP address for which they control the reverse DNS zone where they can place the malicious DNS record.

Credits: This vulnerability was found by Florian Weimer of the Red Hat Product Security Team (https://access.redhat.com/security/team/)