Note that wolfSSL before 5.9.2 required building with
WOLFSSL_ECDHX_SHARED_NOT_ZERO, which was added with 5.3.0, to get and
explicit check. Since the plugin validates the public key, the test case
fails nonetheless.
While RFC 7748 states implementations MAY perform such a check, e.g.
TLS 1.3 explicitly requires it (RFC 8446, section 7.4.2).
Fixes: 7f9bfacd5a ("curve25519: Add a plugin providing Curve25519 DH using backend drivers")
The WC_RNG instances are potentially shared between different threads
as private key objects are refcounted. This may corrupt their internal
state as they are not thread-safe.
For ECDSA, using separate instances for each signing operation has some
performance impact, but for signature operations that should be fine.
The implementation for RSA uses mutexes. That's due to the weird API.
While RNG instances can be passed for signing and encryption (probably
because they are also required for padding/salt besides blinding), they
can't for verifying and decryption. The latter use an RNG instance that
has to be set on the key object before calling these operations. So we
could potentially split the strategy, but to keep this consistent within
the RSA implementation, just continue with the shared RNG but use a
mutex around the API calls.
Fixes: c92eade82c ("wolfssl: Add wolfSSL plugin for cryptographic implementations")
The `aead_t` interface states that `decrypt()` only allocates a plaintext
buffer if successful, so callers might not free it if the call failed.
Fixes: 313811b72d ("aesni: Add a GCM AEAD based on the AES-NI key schedule")
This was added with 5ce3c9b15a ("watcher: Rebuild fdset when select()
fails"), i.e. before switching to poll(), solely to suppress errors when
FDs are closed and select() would return with an error. With poll()
this should not happen result in an error (it potentially indicates this
via POLLNVAL in revents of that FD in the array).
Because the flag was not consistently changed/read with the mutex held,
some analysis tools got confused and imagined wild deadlock scenarios.
The two fields were swapped in the calculation and the new code also
avoids overflowing on 32-bit systems.
Fixes: 4cb0e1bb76 ("Added basic support for PGP certificates (no trust relationships yet)")
Because the CFLAGS applied to the whole plugin, the compiler could
"optimize" the boilerplate plugin code, which could then cause a SIGILL
on hardware that doesn't support such instructions. This change makes
sure only the actual AES implementation is compiled like that, which
would then not get registered depending on the CPU feature detection.
The clone() method was missing a branch when there is an encoded chunk
of length 0 that still needed to be cloned. Otherwise, the destruction
of the clone frees the same pointer that the original owns.
This double free was found with an improved `fuzz_ids` fuzz harness and
a two byte input to create an identification from "@#" or [0x40, 0x23].
It can also be triggered with `<type>:#` e.g. `dns:#`.
One of the problematic constructors is used to parse EAP-Identities,
which are cloned before storing them in the auth-cfg. So this can be
triggered by an unauthenticated attacker.
Note that while the length check was already added with 418dbd6243
("cloning %any ID without zero-byte memleak") and identities that trigger
this can be created since 86ab5636c2 ("support for @#hex ID_KEY_ID
identification_t"), it was the referenced commit that made the length
check problematic.
Fixes: 2147da40a5 ("simplified identification_t.clone() using memcpy")
Fixes: CVE-2026-47895
It seems that 18a94525a7 was a bit hasty. Apparently, it's still the
case that there were reports (at least in some test scenarios). Luckily,
the new facility added in the previous commit allows us to whitelist
these allocations without having to ignore all unknown memory.
With glibc, there is an issue if TZ is not set, which causes a change
of the internally cached TZ value. Because the original value was
cached before LD was active via `init_static_allocations()`, the memory
is freed as unknown memory later. This change allows whitelisting
a function that might free such memory (tzset() only for now).
While the validity of a pre-trusted certificate for which an issuer is
found is enforced via `check_certificate()`, the validity of such a
certificate in an incomplete trust chain, or rather that of the last
certificate in such a chain, was not enforced. This fixes that
inconsistency.
Unlike `struct ifreq` that's used for IPv4, `struct in6_ifreq` contains
not a `struct sockaddr[_in6]` but only a `struct in6_addr`.
Setting addresses like this is currently not used on Linux (the feature
was added to install virtual IPs on FreeBSD/macOS).
Fixes: fccc76449d ("tun-device: Fix handling of IPv6 addresses")
Keys loaded via generic loader (KEY_ANY) or from a PKCS#12 file (or an
engine) don't go through the openssl_ec_private_key_load() constructor
that checks for explicit parameters.
This was broken since the Botan 3 release, which removed the EMSA1
class and the define. The "EMSA1()" wrapper when signing/verifying is
technically not necessary anymore since then (it's deprecated but still
accepted). But to still support Botan 2, we keep that in for now.
The leak detective doesn't wrap this function and calling the original
causes unknown memory frees and even segmentation faults. This is now
triggered with OpenSSL 4 as the implementation of ECP256 uses
OPENSSL_aligned_alloc_array().
Setting a custom memory functions forces OpenSSL to implement aligned
allocations internally, using the registered allocation function.
Using the return value of i2d_* directly as input of chunk_alloc imposes
the risk of creating an invalid chunk when the return value of the i2d_*
function is -1. The openssl_i2chunk macro is meant to avoid this.
Signed-off-by: Thomas Egerer <[email protected]>
This fixes a potential crash due to a null-pointer dereference if rsadp()
returns NULL (e.g. with an all-zero ciphertext).
And it also implements the PKCS#1 v1.5 decryption padding check in
constant time.
The timing leak caused by the previous implementation was measured at
~17.5 μs at 3 GHz, which could allow a Bleichenbacher-like attack in
LAN environments. However, because of how RSA encryption is used in
strongSwan, this is not that much of an issue in practice. The mechanism
is only used for two use cases. One is SCEP/EST via PKCS#7 enveloped
data. Fortunately, this can not be triggered in significant numbers by
an attacker. The other use case is TLS as used by EAP methods (EAP-TLS,
EAP-PEAP/TTLS) during the authentication. While the cipher suites that
use RSA encryption are still enabled by default, the TLS messages are
wrapped in EAP and encrypted by IKE, making any kind of attack difficult.
Note that the gmp plugin isn't enabled anymore by default. And even
before that, most setups had the openssl plugin enabled, which has
priority over the gmp plugin. So it's unlikely the plugin was used in
practice.
Fixes: d615ffdcf3 ("implement gmp_rsa_private_key.decrypt()")
Fixes: CVE-2026-35334
As the previous issue, this can be triggered via IKEv1 CERT payloads.
Fixes: d7aa09104f ("Implement PKCS#7 enveloped-data parsing and decryption")
Fixes: CVE-2026-35329
Can be triggered via empty PKCS#7 encrypted content in IKEv1 CERT payload.
Fixes: 4076e3ee91 ("Extract PKCS#5 handling from pkcs8 plugin to separate helper class")
Fixes: CVE-2026-35329
There is an issue similar to the one fixed with the previous commit when
using directoryName (DN) name constraints. Some RDNs have to be matched
in a case-insensitive manner, which we e.g. do in
`identification.c::rdn_equals`. By not doing it for name constraints,
a malicious intermediate CA could evade an excluded name constraint
just by modifying the case in such an RDN.
While we could use the mentioned function in `dn_matches`, this doesn't
properly fix the problem because the function is basically too strict.
Especially in regards to RDNs of type UTF8String, which are only compared
binary. To match these properly, we'd have to implement the string
preparation described in RFC 5280, section 7.1 and the referenced RFCs.
Until that's the case, we reject excluded name constraints of type
directoryName as we are unable to enforce them.
Fixes: a2b340764f ("Implemented NameConstraint matching in constraints plugin")
Fixes: CVE-2026-35331
The case is generally ignored when matching such identities. So this is
an issue with excluded name constraints where a malicious intermediate
CA could evade the constraints by issuing certificates with names that
just modify the case (e.g. strongSwan.org instead strongswan.org).
Note that it's likely that permitted name constraints are preferred over
excluded name constraints as it might be difficult to come up with a
conclusive list of names to exclude.
Fixes: a2b340764f ("Implemented NameConstraint matching in constraints plugin")
Fixes: CVE-2026-35331
wolfSSL 5.9.1 starts to enforce a minimum (and maximum) length for the
hash when signing. Since we'll always require SHA-1, use 20 bytes as
input in the tests to succeed with SIGN_ECDSA_WITH_NULL.
This mainly intended as defense-in-depth measure to avoid parsing
massively nested structures that could cause a call stack overflow due
to the massive recursion. In particular PKCS#7 signed data is prone to
this as these can be nested basically infinitely. When used in IKEv1 via
ENC_PKCS7_WRAPPED_X509 CERT payloads, our default of 10000 bytes for IKE
messages guards against this, but that's configurable and there might be
a chance for some bug that triggers problematic recursive parsing for
smaller input.
The upper limit is chosen arbitrarily, but there are currently no known
cases that require a depth of more than 10 levels.
Tobias Brunner