strongSwan 4.5.0 < 6.0.5 EAP-TTLS AVP Parsing Integer Underflow

https://blog.trailofbits.com/2026/02/18/carelessness-versus-craftsmanship-in-cryptography/ reports: Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV in their AES-CTR API, leading to a large number of key/IV reuse bugs. These bugs potentially affect thousands of downstream projects. [...] Reusing a key/IV pair leads to serious security issues: if you encrypt two messages in CTR mode or GCM with the same key and IV, then anybody with access to the ciphertexts can recover the XOR of the plaintexts, and that’s a very bad thing. [...] As you might guess from the names, aes-js and pyaes are JavaScript and Python libraries that implement the AES block cipher. They’re pretty widely used: the Node.js package manager (npm) repository lists 850 aes-js dependents as of this writing, and GitHub estimates that over 700,000 repositories integrate aes-js and nearly 23,000 repositories integrate pyaes, either as direct or indirect dependencies. [...] The default IV problem ---------------------- We’ll start with the biggest concern Trail of Bits identified: when instantiating AES in CTR mode, aes-js and pyaes do not require an IV. Instead, if no IV is specified, libraries will supply a default IV of 0x00000000000000000000000000000001.

Worse still, the documentation provides examples of this behavior as typical behavior. For example, this comes from the pyaes README:

aes = pyaes.AESModeOfOperationCTR(key) plaintext = "Text may be any length you wish, no padding is required" ciphertext = aes.encrypt(plaintext)

The first line ought to be something like aes = pyaes.AESModeOfOperationCTR(key, iv), where iv is a randomly generated value. Users who follow this example will always wind up with the same IV, making it inevitable that many (if not most) will wind up with a key/IV reuse bug in their software. Most people are looking for an easy-to-use encryption library, and what’s simpler than just passing in the key?

That apparent simplicity has led to widespread use of the “default,” creating a multitude of key/IV reuse vulnerabilities.

Other issues ============

Lack of modern cipher modes ---------------------------

aes-js and pyaes don’t support modern cipher modes like AES-GCM and AES-GCM-SIV. In most contexts where you want to use AES, you likely want to use these modes, as they offer authentication in addition to encryption. This is no small issue: even for programs that use aes-js or pyaes with distinct key/IV pairs, AES CTR ciphertexts are still malleable: if an attacker changes the bits in the ciphertext, then the resulting bits in the plaintext will change in exactly the same way, and CTR mode doesn’t provide any way to detect this. This can allow an attacker to recover an ECDSA key by tricking the user into signing messages with a series of related keys.

Cipher modes like GCM and GCM-SIV prevent this by computing keyed “tags” that will fail to authenticate when the ciphertext is modified, even by a single bit. Pretty nifty feature, but support is completely absent from aes-js and pyaes.

Timing problems ---------------

On top of that, both aes-js and pyaes are vulnerable to side-channel attacks. Both libraries use lookup tables for the AES S-box, which enables cache-timing attacks. On top of that, there are timing issues in the PKCS7 implementation, enabling a padding oracle attack when used in CBC mode.

Lack of updates ---------------

aes-js hasn’t been updated since 2018. pyaes hasn’t been touched since 2017. Since then, a number of issues have been filed against both libraries. Here are just a few examples:

- Outdated distribution tools for pyaes (it relies on distutils, which has been deprecated since October 2023) - Performance issues in the streaming API - UTF-8 encoding problems in aes-js - Lack of IV and key generation routines in both

Developer response ------------------

Finally, in 2022, an issue was filed against aes-js about the default IV problem. The developer’s response ended with the following:

The AES block cipher is a cryptographic primitive, so it’s very important to understand and use it properly, based on its application. It’s a powerful tool, and with great power, yadda, yadda, yadda. :) [...] In November 2025, we reached out to the maintainer via email and via X, but we received no response. [...] We identified several pieces of software impacted by the default IV behavior in pyaes and aes-js. Many of the programs we found have been deprecated, and we even found a couple of vulnerable wallets for cryptocurrencies that are no longer traded. We also picked out a large number of programs where the security impact of key/IV reuse was minimal or overshadowed by larger security concerns (for instance, there were a few programs that reused key/IV pairs, but the key was derived from a 4-digit PIN).

However, one of the programs we found struck us as important: a VPN management suite.

strongMan VPN Manager ---------------------

strongMan is a web-based management tool for folks using the strongSwan VPN suite. It allows for credential and user management, initiation of VPN connections, and more. It’s a pretty slick piece of software; if you’re into IPsec VPNs, you should definitely give it a look.

strongMan stored PKCS#8-encoded keys in a SQLite database, encrypted with AES. As you’ve probably guessed, it used pyaes to encrypt them in CTR mode, relying on the default IV. In PKCS#8 key files, RSA private keys include both the decryption exponent and the factors of the public modulus. For the same modulus size, the factors of the modulus will “line up” to start at the same place in the private key encodings about 99.6% of the time. For a pair of 2048-bit moduli, we can use the XOR of the factors to recover the factors in a matter of seconds.

Even worse, the full X.509 certificates were also encrypted using the same key/IV pair used to encrypt the private keys. Since certificates include a huge amount of predictable or easily guessable data, it’s easy to recover the keystream from the known X.509 data, and then use the recovered keystream to decrypt the private keys without resorting to any fancy XORed-factors mathematical trickery.

In short, if a hacker could recover a strongMan user’s SQLite file, they could immediately impersonate anyone whose certificates are stored in the database and even mount person-in-the-middle attacks. Obviously, this is not a great outcome.

We privately reported this issue to the strongSwan team. Tobias Brunner, the strongMan maintainer, provided an absolute model response to a security issue of this severity. He immediately created a security-fix branch and collaborated with Trail of Bits to develop stronger protection for his users. This patch has since been rolled out, and the update includes migration tools to help users update their old databases to the new format.

Doing it right --------------

There were several viable approaches to fixing this issue. Adding a unique IV for each encrypted entry in the database would have allowed strongMan to keep using pyaes, and would have addressed the immediate issue. But if the code has to be changed, it may as well be updated to something modern.

After some discussion, several changes were made to the application:

- pyaes was replaced with a library that supports modern cipher modes. - CTR mode was replaced with GCM-SIV, a cipher mode that includes authentication tags. - Tag-checking was integrated into the decryption routines. - A per-entry key derivation scheme is now used to ensure that key/IV pairs don’t repeat.

On top of all that, there are now migration scripts to allow strongMan users to seamlessly update their databases.

There will be a security advisory for strongMan issued in conjunction with this fix, outlining the nature of the problem, its severity, and the measures taken to address it. Everything will be out in the open, with full transparency for all strongMan users. See the full original blog post for further details and some strong opinions omitted above.

For the strongMan issue, see: https://github.com/strongswan/strongMan/security/advisories/GHSA-88w4-jv97-c8xr

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

strongMan is a management interface for strongSwan, an OpenSource IPsec-based VPN. When storing credentials in the database (private keys, EAP secrets), strongMan encrypts the corresponding database fields. So far it used AES in CTR mode with a global database key. Together with an initialization vector (IV), a key stream is generated to encrypt the data in the database fields. But because strongMan did not generate individual IVs, every database field was encrypted using the same key stream. An attacker that has access to the database can use this to recover the encrypted credentials. In particular, because certificates, which have to be considered public information, are also encrypted using the same mechanism, an attacker can directly recover a large chunk of the key stream, which allows them to decrypt basically all other secrets especially ECDSA private keys and EAP secrets, which are usually a lot shorter. Version 0.2.0 fixes the issue by switching to AES-GCM-SIV encryption with a random nonce and an individually derived encryption key, using HKDF, for each encrypted value. Database migrations are provided to automatically re-encrypt all credentials.

In the eap-mschapv2 plugin (client-side) in strongSwan before 6.0.3, a malicious EAP-MSCHAPv2 server can send a crafted message of size 6 through 8, and cause an integer underflow that potentially results in a heap-based buffer overflow.

A vulnerability was found in Ruijie EG306MG 3.0(1)B11P309. It has been rated as problematic. This issue affects some unknown processing of the file /etc/strongswan.conf of the component strongSwan. The manipulation of the argument idontcareaboutsecurityanduseaggressivemodepsk leads to missing encryption of sensitive data. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The vendor was contacted early about this disclosure but did not respond in any way.

In TRENDnet TEW-WLC100P 2.03b03, the idontcareaboutsecurityanduseaggressivemodepsk option is enabled in the strongSwan configuration file, so that IKE Responders are allowed to use IKEv1 Aggressive Mode with Pre-Shared Keys to conduct offline attacks on the openly transmitted hash of the PSK.

strongSwan versions 5.9.2 through 5.9.5 are affected by authorization bypass through improper validation of certificate with host mismatch (CWE-297). When certificates are used to authenticate clients in TLS-based EAP methods, the IKE or EAP identity supplied by a client is not enforced to be contained in the client's certificate. So clients can authenticate with any trusted certificate and claim an arbitrary IKE/EAP identity as their own. This is problematic if the identity is used to make policy decisions. A fix was released in strongSwan version 5.9.6 in August 2022 (e4b4aabc4996fc61c37deab7858d07bc4d220136).

strongSwan before 5.9.12 has a buffer overflow and possible unauthenticated remote code execution via a DH public value that exceeds the internal buffer in charon-tkm's DH proxy. The earliest affected version is 5.3.0. An attack can occur via a crafted IKESAINIT message.

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.

strongSwan before 5.9.8 allows remote attackers to cause a denial of service in the revocation plugin by sending a crafted end-entity (and intermediate CA) certificate that contains a CRL/OCSP URL that points to a server (under the attacker's control) that doesn't properly respond but (for example) just does nothing after the initial TCP handshake, or sends an excessive amount of application data.

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.

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 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 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

Last updated 25 August 2025

In verifyemsapkcs1signature() in gmprsapublickey.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data in the digestAlgorithm.parameters field during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication. This is a variant of CVE-2006-4790 and CVE-2014-1568.

In verifyemsapkcs1signature() in gmprsapublickey.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data after the encoded algorithm OID during PKCS#1 v1.5 signature verification. Similar to the flaw in the same version of strongSwan regarding digestAlgorithm.parameters, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication.

Last updated 25 August 2025

In strokesocket.c in strongSwan before 5.6.3, a missing packet length check could allow a buffer underflow, which may lead to resource exhaustion and denial of service while reading from the socket.

The rsapssparamsparse function in libstrongswan/credentials/keys/signatureparams.c in strongSwan 5.6.1 allows remote attackers to cause a denial of service via a crafted RSASSA-PSS signature that lacks a mask generation function parameter.

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.

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 [ ... ]").

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.

strongSwan before 5.1.2 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon crash) via a crafted IDDERASN1DN ID payload.

IKEv2 in strongSwan 4.0.7 before 5.1.3 allows remote attackers to bypass authentication by rekeying an IKESA during (1) initiation or (2) re-authentication, which triggers the IKESA state to be set to established.

strongSwan 5.0.2 through 5.1.0 allows remote attackers to cause a denial of service (NULL pointer dereference and charon daemon crash) via a crafted IKEv1 fragmentation packet.