The option was renamed with 7f9f9bd375 ("Fixed some typos, courtesy of
codespell"), the check was not.
Fixes: dd7b0283ef ("plugin-loader: Add option to change log message if plugin is not found")
Because the `derived` flag was not reset (it's set after the initial
IKE_SA_INIT exchange), no keys would get derived when sending
IKE_INTERMEDIATE during the next try. As there is then no `aead_t`
available, encrypting the message would fail and the initiation would
remain stuck.
Fixes: 0d49ddec2e ("ike-init: Add support for multiple key exchanges")
This reverts commit b998695344.
Seems like this is not necessary anymore. Possibly because of
8ff3238027 ("openssl: Prevent OpenSSL from using posix_memalign() if
LD is enabled").
In a targeted request, the software ID is provided by the IMV. If no
database is used (which is not the recommended setup), the ID is not
validated and could potentially contain special characters. With the
previous command string construction and use of popen(), which runs a
shell, that could potentially allow running arbitrary commands.
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 missing parentheses around the additions when calculating optlen
in the previous code can cause an out-of-bound read of up to 228 bytes
if no DHCP_OPTEND is found in the message (the calculation basically
evaluated to `- 20 + 8 + 240`).
Since the buffer for the received packet (via pf_handler_t) is located
on the stack, this shouldn't cause much of an issue in practice.
We don't want to build old versions using these caches, so we don't
need old entries (if header files change, there could be lots of
differences that increase the cache size unnecessarily).
These are shared by many tests, in particular the "all", "coverage",
"no-dbg" and "no-testable-ke" tests, which each would otherwise require
their own large cache.
Similarly, the "codeql" and "sonarcloud" tests rely on the same
dependencies but only the latter uses ccache for the strongSwan build.
Also reduce the maximum size per cache for all workflows to keep them
in check over time (some could even be set lower, we'll have to see
how this develops).
As mentioned in the previous commit, ASAN does a fine job detecting leaks
during the tests. We just add a single LD-enabled build of the "default"
test here to test the basic functionality.
And we continue to use leak detective in our testing environment to keep
the memory requirements low.
We don't need a separate cache for the "apidoc" test and while the
"dist" test is similar as well, it builds in a different directory,
which means that config.h causes a cache miss for everything but the
configure checks.
The special handling caused a significant diff between builds with and
without LD, which made ccache less effective as we only store the cache
once for the build without LD.
However, despite this change, while it previously was the case that the
LD vs. non-LD builds didn't differ much, that's not the case anymore
nowadays. In particular the --disable-asan option and the BFD-based
backtraces for the native OpenSSL builds (e.g. default or openssl-sys)
cause quite a significant diff. As cache storage is limited, we keep
the current behavior for now. But it might be an option to reduce or
even remove the LD builds in the future as ASAN seems do the job pretty
well and we still use LD in the testing environment.
The others are either included already in the "all" build (to which we
now switch) or they have a relatively small diff to that (e.g. gcrypt
only differs in that relatively small plugin). For the "openssl-sys"
build, we can rely on the "default" build but only on ubuntu-latest as
we don't build that on ubuntu-22.04.
Let's try this again :) Since cache entries with the same key are not
updated/replaced and there is no option to do so, we manually delete the
previous entry for the current branch.
This reduces the cache storage for active branches, which can cause
caches of the master branch to get evicted, which in turn will slow down
builds of not only master but also new branches as they can't fall back
on those caches.
Permission has to be explicitly granted in order to delete the cache
entries when not using the legacy all-write tokens that are the default
for old repositories.
The continue-on-error option is set for the step that deletes the old
cache entry as it's expected that cache-hit will be true for a new feature
branch when restoring the cache from the master branch. However, because
there won't be anything to delete for this branch yet, the command will
fail. The --succeed-on-no-caches option of the command unfortunately
only works with --all.
For the Linux tests, several jobs use the same cache key. So there is
a chance that two jobs try to store a new entry concurrently, which will
fail (it works if there was a cache hit and they are slightly off as
previous entries are first deleted). To avoid that, we store the cache
only for one particular config.
Also made sure that the "openssl" test does not remove "openssl-3/4"
caches by adding a suffix to the former.
For alpine, the repository had to be set explicitly as gh wasn't able to
determine it (didn't detect the Git working dir).
While continue-on-error can be configured more specifically (e.g. also
would allow to handle "default" and "printf-builtin" tests that rely
on debug symbols), it also lets the workflow succeed if any of these
jobs fail. That's not ideal if there is an actual error and not
just an intermittent package sync problem.
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.
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
If the extension doesn't contain a multiple of two bytes, the previous
code would get stuck in an infinite loop as `remaining()` continued to
return TRUE while `read_uint16()` failed to parse a value. Initiating
several connections with such an extension allows a DoS attack as no
threads would eventually be available to handle packets/events.
Fixes: 7fbe2e27ec ("tls-server: TLS 1.3 support for TLS server implementation")
Fixes: CVE-2026-35328
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
This prevents a crash due to a null-pointer dereference when processing
an empty ECDH public key.
The previous length check only applied in the `!ec` case, so in the `ec`
case, the access to `pub.ptr[0]` was unguarded. If a crafted TLS
record ends with an empty ClientKeyExchange, then `read_data8` sets
`pub` to `chunk_empty`, causing a null-pointer dereference.
Note that if some data follows the empty ClientKeyExchange, this just
causes a 1-byte out-of-bounds read that has no further effect as the
TLS session is aborted immediately. Either because the read value
doesn't equal TLS_ANSI_UNCOMPRESSED or because the empty public key
is rejected by `set_public_key()`.
The referenced commit that introduced the pointer access, added the
check for `pub.len` specifically to the `!ec` case, while the pointer
access was initially unconditional (probably because the code was just
copied from `tls_peer.c` which processes ECDH public keys in a separate
function, so there was no `ec` flag). The latter was fixed a couple of
days later with 7b3c01845f ("Read the compression type byte for EC
groups, only"). However, that commit didn't change the length check.
Anyway, it's possible that the original intention was to add the check
to the `ec` case on the previous line, or that there was some confusion
with the parenthesis and something like the current code was intended to
begin with.
Fixes: e6cce7ff0d ("Prepend point format to ECDH public key")
Fixes: CVE-2026-35332
These are quite a bit faster than on AppVeyor (with ccache about a fifth,
without less than half - and they run concurrently).
We only keep the AppVeyor builds for now to test against those old
OpenSSL versions (1.1.1 and 1.0.2) for which there is still extended
support available. Even simplified like that they still take longer
than the builds on GA.
This reduces the cache storage for active branches and since caches for
different branches are separate and we abort previous builds of the same
branch, this is not necessary to ensure caches can successfully be stored.
We are still too close to the limit of 1 hour (at least with the 2019
image and the 2022 image is about the same), so reduce the build time by
not building libimcv natively, which saves about 10 minutes.
Also, only build against OpenSSL 1.0.2 (on the 2017 image) and 1.1.1 (on
the 2019 image) as these are the only versions for which OpenSSL provides
extended support.
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.
All the plugins are linked statically into the binaries, so there
is no reason to set the directories that are only required when loading
them from files.
The pa_tnc fuzzer does not rely on any plugins and the pb_tnc fuzzer is
a bit special in that it does use code from the tnccs-20 plugin, but that
doesn't actually have to be loaded as such. The fuzzer directly calls
statically linked code from the plugin.
The `cipher_suites` field has a 16-bit length field, so up to 32k 2-byte
cipher suites could technically be proposed. With `tls_cipher_suite_t`
typically being 4 bytes wide, the necessary allocation for the temporary
array can be up to 128 KiB. Even though this should be fine on typical
systems, we avoid potentially overflowing the stack by using malloc()
instead of alloca().
These certificate requests also contain SHA-1 hashes, which is assumed
in `ike_cert_pre.c::process_certreq()` when enumerating key IDs.
Because the parser allocates a separate chunk for the data and the
enumerator doesn't read beyond that chunk's length after the first
iteration, only lengths between 1 and 19 are problematic (0 doesn't
cause an enumeration because chunk_empty is assigned).
Whether the OOB read then can cause a segmentation fault depends on the
allocator, its alignment rules, and its minimum overhead. For instance,
with glibc on a typical 64-bit system (8 bytes for pointers and size_t),
the alignment is 16 bytes and the minimum allocated size is 32 bytes,
with typically 24 that are technically available for data, even if only
0 bytes are allocated (as returned by `malloc_usable_size()`). So with
an allocation between 1 and 19, we can always safely read 20 bytes.
Assuming that other allocators behave similar for small allocations, it
seems unlikely that this causes a crash.
Fixes: 15612b3a42 ("Add support for IKEv2 OCSP extensions (RFC 4806)")
`xmlNodeGetContent()` returns `NULL` if `child` is `NULL`, which causes
a segmentation fault in `chunk_from_str()`.
Fixes: ec1eab0319 ("fixed XML parsing of TNCCS 1.1 ReasonString message")
The RFC only allows that the number of fragments increases (if the
sender reduces the MTU).
Not enforcing this before could cause early reassembly as the trigger was
that the number of received fragments matches the total count of the
current packet (which was a bit weird anyway). Only an active MITM could
trigger this as individual fragments are encrypted and authenticated.
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.
If nothing was read from the message, the previous code could result in
a crash depending on where `ext.ptr` pointed to, as determined by the
current stack contents. Since TLS 1.3 is still disabled by default and
this is usually used for TLS-based EAP methods after validating the
IKEv2 server's certificate, the real world impact seems relatively low.
Fixes: 9ef46cfaf9 ("tls-peer: Mutual authentication support for TLS 1.3")
These attributes contain a 16-bit length field for the actual length of
the data in bits or bytes, as compared to the length in 4-byte blocks in
the attribute header. The previous code didn't correctly account for the
length of the fixed header (4 bytes) when it compared the parsed length
to the length in the header. This could cause an out-of-bounds read of
up to four bytes beyond the end of the attribute/message.
Fixes: f8330d0395 ("Added a libsimaka library with shared message handling code for EAP-SIM/AKA")
The length field in the AVP header includes the 8 bytes of the header
itself. Not checking for that and later subtracting it causes an
integer underflow that usually triggers a crash when accessing a
NULL pointer that resulted from the failing chunk_alloc() call because
of the high value.
The attempted allocations for invalid lengths (0-7) are 0xfffffff8,
0xfffffffc, or 0x100000000 (0 on 32-bit hosts), so this doesn't result
in a buffer overflow even if the allocation succeeds.
Fixes: 79f2102cb4 ("implemented server side support for EAP-TTLS")
Fixes: CVE-2026-25075
To make the default strongswan.conf, with `load_modular` enabled, work
if charon itself is not built, we enable generating the charon-specific
snippets also for the two other daemons that fall back on reading
options from the `charon` section.
VICI_END (7) shouldn't be encoded in a message. However, if we encounter
it, we should at least set `out` accordingly so callers can abort the
enumeration. By not doing so previously and returning TRUE, callers
might access the possibly uninitialized name/value arguments passed to
the enumerator.
This ensures that we don't load a key with e=1, which basically renders
RSA into a no-op. Since keys are universally generated with e=65537 and
no reputable CA will sign keys with e=1, allowing this before didn't have
any real world impact.
Tobias Brunner