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.

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

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.

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.

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.

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.

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

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

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.

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

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.

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.

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 vulnerability was found in libreswan 3.17. IKEv2 bogus proposal lacking DH transform causes pluto daemon to restart.