The gmp plugin in strongSwan before 5.6.0 allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted RSA signature.
The ASN.1 parser in strongSwan before 5.5.3 improperly handles CHOICE types when the x509 plugin is enabled, which allows remote attackers to cause a denial of service (infinite loop) via a crafted certificate.
The gmp plugin in strongSwan before 5.5.3 does not properly validate RSA public keys before calling mpzpowmsec, which allows remote peers to cause a denial of service (floating point exception and process crash) via a crafted certificate.
strongSwan 5.9.8 and 5.9.9 potentially allows remote code execution because it uses a variable named "public" for two different purposes within the same function. There is initially incorrect access control, later followed by an expired pointer dereference. One attack vector is sending an untrusted client certificate during EAP-TLS. A server is affected only if it loads plugins that implement TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, or EAP-TNC). This is fixed in 5.9.10.
The in-memory certificate cache in strongSwan before 5.9.4 has a remote integer overflow upon receiving many requests with different certificates to fill the cache and later trigger the replacement of cache entries. The code attempts to select a less-often-used cache entry by means of a random number generator, but this is not done correctly. Remote code execution might be a slight possibility.
The gmp plugin in strongSwan before 5.9.4 has a remote integer overflow via a crafted certificate with an RSASSA-PSS signature. For example, this can be triggered by an unrelated self-signed CA certificate sent by an initiator. Remote code execution cannot occur.
The comparedn function in utils/identification.c in strongSwan 4.3.3 through 5.1.1 allows (1) remote attackers to cause a denial of service (out-of-bounds read, NULL pointer dereference, and daemon crash) or (2) remote authenticated users to impersonate arbitrary users and bypass access restrictions via a crafted IDDERASN1DN ID, related to an "insufficient length check" during identity comparison.
strongSwan 4.2.6 and earlier allows remote attackers to cause a denial of service (daemon crash) via an IKESAINIT message with a large number of NULL values in a Key Exchange payload, which triggers a NULL pointer dereference for the return value of the mpzexport function in the GNU Multiprecision Library (GMP).
The asn1length function in strongSwan 2.8 before 2.8.11, 4.2 before 4.2.17, and 4.3 before 4.3.3 does not properly handle X.509 certificates with crafted Relative Distinguished Names (RDNs), which allows remote attackers to cause a denial of service (pluto IKE daemon crash) via malformed ASN.1 data. NOTE: this is due to an incomplete fix for CVE-2009-2185.
The ASN.1 parser (pluto/asn1.c, libstrongswan/asn1/asn1.c, libstrongswan/asn1/asn1parser.c) in (a) strongSwan 2.8 before 2.8.10, 4.2 before 4.2.16, and 4.3 before 4.3.2; and (b) openSwan 2.6 before 2.6.22 and 2.4 before 2.4.15 allows remote attackers to cause a denial of service (pluto IKE daemon crash) via an X.509 certificate with (1) crafted Relative Distinguished Names (RDNs), (2) a crafted UTCTIME string, or (3) a crafted GENERALIZEDTIME string.
The GMP Plugin in strongSwan 4.2.0 through 4.6.3 allows remote attackers to bypass authentication via a (1) empty or (2) zeroed RSA signature, aka "RSA signature verification vulnerability."
The isasn1 function in strongSwan 4.1.11 through 5.0.4 does not properly validate the return value of the asn1length function, which allows remote attackers to cause a denial of service (segmentation fault) via a (1) XAuth username, (2) EAP identity, or (3) PEM encoded file that starts with a 0x04, 0x30, or 0x31 character followed by an ASN.1 length value that triggers an integer overflow.
Buffer overflow in the atodn function in strongSwan 2.0.0 through 4.3.4, 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.
strongSwan 4.5.x through 5.2.x before 5.2.1 allows remote attackers to cause a denial of service (invalid pointer dereference) via a crafted IKEv2 Key Exchange (KE) message with Diffie-Hellman (DH) group 1025.
The server implementation of the EAP-MSCHAPv2 protocol in the eap-mschapv2 plugin in strongSwan 4.2.12 through 5.x before 5.3.4 does not properly validate local state, which allows remote attackers to bypass authentication via an empty Success message in response to an initial Challenge message.
strongSwan 4.3.0 through 5.x before 5.3.2 and strongSwan VPN Client before 1.4.6, when using EAP or pre-shared keys for authenticating an IKEv2 connection, does not enforce server authentication restrictions until the entire authentication process is complete, which allows remote servers to obtain credentials by using a valid certificate and then reading the responses.
A flaw was found in the strongSwan payload handling code. This flaw can be triggered by an IKEv1 or IKEv2 message that contains payloads that are only defined for the respective other IKE version. For instance, sending an IKEv1 Main Mode message containing a payload with type 41 (IKEv2 Notify) will crash the daemon or, potentially allow for remote code execution, when a short summary of the contents of the message is logged ("parsed IDPROT request 0 [ ... ]").
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 strongSwan before 5.9.5, a malicious responder can send an EAP-Success message too early without actually authenticating the client and (in the case of EAP methods with mutual authentication and EAP-only authentication for IKEv2) even without server authentication.