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.
This doesn't really seem useful (perhaps it was before we started to
configure the outbound interface on our routes). And it can actually
cause the route installation to fail e.g. for routes over point-to-point
interfaces where we'd get "Error: Nexthop has invalid gateway" errors.
Note that we can't return NULL if we find an interface as e.g. the updown
plugin uses this method to determine the outbound interface (it ignores
the nexthop), which it passes to the script. If we returned NULL, it
would pass "unknown" instead, which would cause the firewall rules to
mismatch. While it seems that 0.0.0.0/:: is ignored as nexthop by the
kernel on the installed route, I still explicitly ignore such addresses
to avoid any unintended side-effects.
The automatic route installation in the ikev2/shunt-manual-prio scenario
had to be disabled on the clients. The reason is that the route in table
220 won't have a nexthop set (the peers are directly connected), so when
trying to reach alice or venus via SSH, which matches the port-specific
bypass policies for which we don't install throw routes, the hosts will
do ARP requests for the target IPs instead of routing the packets via
moon.
Closesstrongswan/strongswan#2548
The action causes errors because it is not compatible to the Docker
version used in the runner images. Unfortunately, it doesn't seem
maintained anymore. The action is simple enough, though, so instead of
switching to a fork, we just use "docker run" directly.
Adds support for ICMP error forwarding that the kernel supports properly
since v6.9 (it still sends locally generated errors from the wrong source
IP, though).
While 3c12905103 ("ipsec: Add function to compare two ipsec_sa_cfg_t
instances") added a comparison function to avoid issues with non-zeroed
padding, hashes were still calculated using chunk_hash().
Uses a separate default plugin list for swanctl (instead of just loading
all of libstrongswan's plugins) to avoid some side-effects of loaded but
unused plugins. The load statements in the regression tests have been
updated accordingly.
A new configure option for maintainers of distributions that ship
plugins in separate packages changes the message if a plugin is not
found and reduces its log level. This confused users of tools that don't
use modular plugin loading (e.g. pki or swanctl).
Also changes command line handling in pki and swanctl so that the shared
options can be passed before the actual command and that the debug level
also affects library/plugin initialization.
References strongswan/strongswan#2971
Similarly to the previous commit for pki, this allows setting these
options before the command, and by pre-parsing them we can see log
messages during the initialization.
This allows setting the log level before initializing the library and
loading the plugins, as well as having the top-level command itself in
an options file.
Distributions like Debian/Ubuntu ship the plugins in multiple packages
that are not all installed by default. When running tools like pki or
swanctl, which don't use modular loading with config snippets by default,
there are errors in the output if these packages and plugins are
currently not available. In order to not alarm users, this change adds
a configure option that package maintainers can use. It causes the log
level of the message to increase and also adds a note that mentions that
plugins are potentially available in other packages (which should be the
case unless the user tried to load a plugin, e.g. via load statement,
that is not actually built and shipped by the package maintainers).
Loading all libstrongswan plugins isn't necessary as the tool only uses
the plugins to parse/decrypt credentials. So it's similar to pki, but
it doesn't do (online) certificate validation, access tokens, or need
access to databases.
While it's usually not an issue to load unnecessary plugins, one thing
that came up recently are the new capabilities required by the agent
plugin. Since Debian's AppArmor policy for swanctl doesn't grant them,
this produces an error message that might confuse users.
This is useful during make-before-break reauthentication, where the
new SA is created before the old one is terminated and the virtual IP
gets released.
This also changes the hash() and equals() functions to avoid potential
collisions.
References strongswan/strongswan#2967
The referenced commit ignored that INVALID_ARG was returned by this
authenticator if an unsupported signature scheme is encountered. This
caused a crash in find_alternative_eap_cfg() as no EAP identity is
stored in the current auth config.
Since we don't distinguish the situation outside of the authenticator,
we can just return FAILED.
Closesstrongswan/strongswan#2979
Fixes: 2f2e4abe3c ("ikev2: Add support to switch peer configs based on EAP-Identities")
In particular with the 2019 image, the time required often exceeded the
maximum of 60 minutes. Using lld reduces the runtime quite a bit (it's
still close to the limit, though).
This doesn't work with the old OpenSSL version we use with the 2015
image (that libeay32.lib file just doesn't seem to work), so continue
to use ld (the build on that image is the quickest anyway).
Such a recursive call occurs when sorting the array of Child SAs inside
an IKE SA that causes comparisons of the child configs and their
proposals, which in turn creates a merged array of all transform types
and that uses array_sort() and array_bsearch().
Closesstrongswan/strongswan#2926
Fixes: 8e7f379f71 ("ike-sa: Sort CHILD_SAs by CPU ID")
We explicitly use untoh16() so this warning isn't relevant:
ip_packet.c:313:42: error: taking address of packed member 'ip_len' of class or structure 'ip' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
This ensures we access the socket as user who NM ran the auth-dialog for,
especially for system-wide connections where the connection does not
mention a user.
We also make sure we don't use the cached socket and user of a previous
connection attempt, because system-wide connections might be used by
different users.
This prevents an attack similar to the one fixed previously where a
user passes the path to credentials of another user, in this case the
path to the agent socket of that user.
This ensures that only certificates/private keys accessible by the
configured user are accessed and prevents attackers from misusing
other user's credentials.
Also removed setting NM_VERSION_MIN_REQUIRED, which suppresses deprecation
warnings that were added with newer API versions, and
NM_VERSION_MAX_ALLOWED, which warns if using functions added in newer
API versions, so we always build against the latest API available.
But we check explicitly for the required function so this works with
older NM versions and automatically will use it if the function is
backported.
Note that we can't use BUILD_FROM_FILE to read the temporary files as that
uses mmap() which SELinux policies prevent us from using at the location
these files are stored ([/var]/run/NetworkManager/cert/).
Fixes: CVE-2025-9615
Some (Windows) peers have been seen to initiate a second rekeying for the
same Child SA. Presumably, this happens if a rekey request from us for
the same old Child SA arrives while it waits for the response to its
first rekey request. Once we receive the delete for the old SA, we
conclude the rekeying with the second replacement. However, the first
replacement remained linked to the old SA. So this change prevents a
crash once the peer sends a delete for that first replacement (which it
seems to do after about 5 minutes).
References strongswan/strongswan#2944Closesstrongswan/strongswan#2945
This ensures that packets on sun are processed on a particular CPU and
not randomly on one, which causes expected SAs not to get created or
other weird things.
Also remove the --enable-md4 option. We never supported MD4 via wolfSSL,
as it's not available via the hash API we use (would require explicit
MD4-specific functions and structures).
Increases buffers in settings and swanctl to allow longer connection
names (up to the limit of 256 characters imposed by VICI). The limit
for names is now also enforced when generating VICI messages.
Closesstrongswan/strongswan#2936
The buffer size for individual parts of a key now match the maximum length
of names in VICI. The full pattern should accommodate several long names
(e.g. for connections and child connections in swanctl) even if no
printf-specifiers are used.
Combines concurrent requests for the same CRL URI by multiple threads.
So only the first thread actually fetches it, the others wait for that
result. This is particularly helpful if the CRL can currently not
be fetched due to DNS or HTTP/LDAP timeouts as it prevents each thread
from having to wait for the complete timeouts, which reduces the number
of SAs that can concurrently be established.
A negative result is cached for a while (currently 3 times the fetch
timeout, i.e. 30 seconds by default) so requests can fail quickly and
threads can continue establishing SAs if they use a relaxed revocation
policy.
Closesstrongswan/strongswan#2918
Using FrameLayout for the settings instead of the recommended
FragmentContainerView because the latter makes handling insets more
complicated (fitsSystemWindows doesn't work as the fragment is responsible
for handling insets but how that should work with PreferenceFragmentCompat
is unclear).
Fixes: 2404b2bee6 ("android: Apply UI changes for edge-to-edge views in Android 15+")
This fixes the vulnerability in the eap-mschapv2 plugin and an issue
with the filename of log files. In the released app, the OpenSSL version
is also increased in order to support ML-KEM.
For message lengths between 6 and 8, subtracting HEADER_LEN (9) causes
`message_len` to become negative, which is then used in calls to malloc()
and memcpy() that both take size_t arguments, causing an integer
underflow.
For 6 and 7, the huge size requested from malloc() will fail (it exceeds
PTRDIFF_MAX) and the returned NULL pointer will cause a segmentation
fault in memcpy().
However, for 8, the allocation is 0, which succeeds. But then the -1
passed to memcpy() causes a heap-based buffer overflow (and possibly a
segmentation fault when attempting to read/write that much data).
Fortunately, if compiled with -D_FORTIFY_SOURCE=3 (the default on e.g.
Ubuntu), the compiler will use __memcpy_chk(), which prevents that buffer
overflow and causes the daemon to get aborted immediately instead.
Fixes: f98cdf7a47 ("adding plugin for EAP-MS-CHAPv2")
Fixes: CVE-2025-62291
Tobias Brunner