This should fix this error thrown by autoreconf:
ld-elf.so.1: /usr/local/lib/perl5/5.32/mach/CORE/libperl.so.5.32: Undefined symbol "strerror_l@FBSD_1.6"
This should make the DoS limits (cookie_threshold[_ip] and block_threshold)
more accurate so that it won't be possible to create lots of jobs from
spoofed IP addresses before half-open IKE_SAs are actually created from
these jobs to enforce those limits.
Note that retransmits are tracked as half-open SAs until they are
processed/dismissed as the check only happens in checkout_by_message().
Increasing the count in process_message_job_create() avoids issues with
missing calls to track_init() before calling checkout_by_message() (e.g.
when processing fragmented IKEv1 messages, which are reinjected via a
process message job).
Because the global cookie threshold is higher than the per-IP block
threshold, it was previously possible for an attacker to block a legitimate
user by sending spoofed IKE_SA_INIT packets from that user's IP.
The timespan for requiring cookies is now also not extended anymore with
every IKE_SA_INIT received during the calm down period. Because this
allowed an attacker, after initially triggering the global cookie threshold,
to force cookies for all clients by sending just a single spoofed
IKE_SA_INIT every 10 seconds.
We keep track of reaching the per-IP threshold in segments of the hashed
IP addresses, so only a (random, due to chunk_hash()'s random key) subset
of clients will receive cookies, if single IPs are targeted.
The default global threshold is increased a bit.
If we are under attack and there are lots of requests, we might hit
the previous use count limit pretty quickly and may switch secrets multiple
times a second, which renders the 10 second default lifetime of COOKIEs
pointless and prevents legitimate clients from sending requests with valid
COOKIEs.
This happens for `/0` subnet masks. In practice, it's not an issue because
if `bytes` is 0, then so are `netbits`, `bits` and `mask`. So the two
incorrectly addressed array elements are not actually modified. The first
operation is a `&= 0xff` and the second a `|= 0`, so nothing changes.
But some tools might not consider the values and report this as undefined
behavior, which it technically is.
Such routes with a gateway that equals the peer's address are problematic
on FreeBSD. And since there is most likely a narrow route for the local
subnet anyway, the exclude routes would be redundant.
When installing routes based on remote traffic selectors, it can be
necessary to install an exclude route for the remote peer to avoid a
routing loop and continue to be able to reach it via IKE/ESP.
However, such routes are only necessary, if the routes we install don't
go via outbound interface. That's the case when using VIPs and routing
via TUN devices, or when using internal source IPs and routing via
their interfaces.
Installing such exclude routes if not necessary can cause issues on
FreeBSD (EINVAL when sending packets to the peer).
There is a conflict between atexit() handlers registered by OpenSSL and
some executables (e.g. swanctl or pki) to deinitialize libstrongswan.
Because plugins are usually loaded after atexit() has been called, the
handler registered by OpenSSL will run before our handler. So when the
latter destroys the plugins it's a bad idea to try to access any OpenSSL
objects as they might already be invalid.
Fixes: f556fce16b ("openssl: Load "legacy" provider in OpenSSL 3 for algorithms like MD4, DES etc.")
Closesstrongswan/strongswan#921
has_subject() already matches the identity against the subject DN and
all the SANs (it actually already did when this check was added with
c811479986 ("Strictly check if the server certificate matches the TLS
server identity")).
The client already enforces that the server identity is contained in the
received certificate. But on the server, the referenced commit changed
the lookup from the configured (or adopted if %any was configured) client
identity to the subject DN of the received client certificate. So any
client with a trusted certificate was accepted.
Fixes: d2fc9b0961 ("tls-server: Mutual authentication support for TLS 1.3")
Closesstrongswan/strongswan#873
This adds some modifications to NAT-D in case the source IP can't be
determined before generating NAT-D notifies. If this happens when using
IPv4, a local NAT is faked (UDP-encap can be disabled later via MOBIKE
if no NAT is actually detected). If it happens when using IPv6, NAT-T
is disabled completely.
It also removes the old fallbacks for source NAT-D notifies, which were
generally unused but could lead to incorrect results in the above
scenario.
Closesstrongswan/strongswan#861
This can happen if an IKE_SA is initiated to a static IP before DHCP is
done. Instead of failing the initiation, we either fake a NAT situation
(for IPv4) or disable NAT-D (for IPv6 where NATs and UDP-encap are not
widely used or supported).
This also removes the old fallbacks to determine the source address(es).
A source address lookup is done in ike_sa_t::resolve_hosts() (wasn't the
case initially) and enumerating local IPs (which was added even earlier)
could still lead to issues if e.g. LAN addresses are available but the
WAN address that's later used is not yet (in which case only the responder
would detect a NAT and UDP-encap would be configured asymmetrically).
To force UDP-encap locally in case there is no actual NAT, we store this
as COND_NAT_HERE instead of COND_NAT_FAKE. This ensures DPDs will contain
NAT-D notifies and we can later remove the state via MOBIKE. We trigger
a MOBIKE update after such a DPD by registering a changed NAT mapping after
checking for a disappearing local NAT, which is very unlikely to happen
outside of a MOBIKE update (where that flag is not checked).
On the recently updated 2019 image, autoreconf is not found anymore, as
recent versions of msys2 don't ship autools with base-devel aymore, so
install the autotools package explicitly.
Without this, the authentication succeeded if the server sent an early
EAP-Success message for mutual, key-generating EAP methods like EAP-TLS,
which may be used in EAP-only scenarios but would complete without server
or client authentication. For clients configured for such EAP-only
scenarios, a rogue server could capture traffic after the tunnel is
established or even access hosts behind the client. For non-mutual EAP
methods, public key server authentication has been enforced for a while.
A server previously could also crash a client by sending an EAP-Success
immediately without initiating an actual EAP method.
Fixes: 0706c39cda ("added support for EAP methods not establishing an MSK")
Fixes: CVE-2021-45079
Optionally load the legacy provider in OpenSSL 3 (enabled, by default) to
make algorithms like MD4 and DES available, which we require for
EAP-MSCHAPv2. Allow explicitly loading the fips provider via existing
fips_mode option. The loaded providers, whether influenced by the above
options or not, are logged.
Closesstrongswan/strongswan#759
We still require these algorithms for e.g. EAP-MSCHAPv2, so the option is
enabled, by default. To use other providers (e.g. fips or even custom
ones), the option can be disabled and the providers to load/activate can
be configured in openssl.cnf. For instance, the following has the same
effect as enabling the option:
openssl_conf = openssl_init
[openssl_init]
providers = providers
[providers]
default = activate
legacy = activate
[activate]
activate = yes
Improves handling failures during unit tests of libtls and includes a
change for the openssl plugin so it only announces ECDH groups for which
the library provides the required ECC curve.
Closesstrongswan/strongswan#752
Determined by whether the library provides curves for it or not.
For instance, in the OpenSSL 3 FIPS provider the Brainpool curves are
not included. And in the Fedora package several weak curves are
explicitly patched out and the Brainpool curves are omitted even in
non-FIPS mode.
In particular as server, the previous code might cause it to hang in
recv() if this case wasn't triggered by a close notify (followed by a
shutdown of the socket) but it e.g. failed processing a ServerHello and
responded with a fatal alert.
Fixes: 09fbaad6bd ("tls-socket: Don't fail reading if sending data failed")
This is useful for kernel implementations where the ordering of SAs
is unpredictable and the new SA might otherwise not be used until the
DELETE response has been received, which is not ideal as the responder
might not keep the old SA around that long. On Linux, it makes no
difference as we switch to the new outbound SA immediately because the
updated outbound policy references its SPI.
Use a Debian-based Docker container to run the unit tests for charon-tkm,
once without and once with TKM running. The container can also be used
locally to run the tests (see comments in the Dockerfile).
This way we can run many unit tests without having to run the TKM in the
background and as regular user. To run the other tests, TESTS_TKM can
optionally be defined when running `make check`.
The default MTU of 1500 is too high if kernel-libipsec is used (considering
the overhead of UDP-encapsulated ESP), but might also have an effect if
a TUN device is only used to install a virtual IP (the route points to it,
so the system might use its MTU and 1500 would still be too high).
This also works around an issue on macOS 12 where no RTM_IFINFO event
is sent for the newly created TUN device (neither for the creation,
setting it "up", nor adding the address). Changing the MTU, however,
triggers such an event and we can detect the virtual IP.
Closesstrongswan/strongswan#707
NULL parameters (for classic PKCS#1 signature schemes) are explicitly
allowed (for any schemes for now), but we only expect parameters for
RSASSA-PSS. Before enforcing this, it was possible to modify the
parameters in the signatureAlgorithm field of the outer X.509 Certificate
structure to something different than the signature field of the signed,
inner tbsCertificate structure, allowing generating infinite versions
of valid certificates with different binary encodings. Now we accept at
most two (NULL and absent parameters).
Previously, only parameters of type OID, SEQUENCE and OCTET STRING were
returned (so e.g. random integers could be put in parameters and we
wouldn't know about it).
Log output is basically the same as with asn1_parser_t before, except
that parameters are always dumped (if any), that wasn't the case before
because ASN1_RAW (instead of ASN1_OBJ) was used.
random() allocates values in the range [0, RAND_MAX], with RAND_MAX usually
equaling INT_MAX = 2^31-1. Previously, values between 0 and 31 were added
directly to that offset before applying`% CACHE_SIZE` to get an index into
the cache array. If the random value was very high, this resulted in an
integer overflow and a negative index value and, therefore, an out-of-bounds
access of the array and in turn dereferencing invalid pointers when trying
to acquire the read lock. This most likely results in a segmentation fault.
Fixes: 764e8b2211 ("reimplemented certificate cache")
Fixes: CVE-2021-41991
The `salt_len` field is signed because negative values are used to indicate
automatic salt lengths when generating signatures. This must never be the
case when validating them.
Not checking this could lead to an integer overflow below. The value is
assigned to the `len` field of a chunk (`size_t`), which is further used
in calculations to check the padding structure and (if that is passed by
a matching crafted signature value) eventually a memcpy() that will result
in a segmentation fault.
Fixes: 7d6b81648b ("gmp: Add support for RSASSA-PSS signature verification")
Fixes: CVE-2021-41990
The `salt_len` member in the struct is of type `ssize_t` because we use
negative values for special automatic salt lengths when generating
signatures. This change ensures that `salt_len` will not overflow the
`len` fields of chunks (`size_t`), which could lead to integer overflows
when validating signatures (see the next commit).
Fixes: a22316520b ("signature-params: Add functions to parse/build ASN.1 RSASSA-PSS params")
If the randomly allocated serial starts with 0x80, the fix added with
e49197f15e ("pki: Don't generate negative random serial numbers in
X.509 certificates") causes the value to become zero. So the encoded
ASN.1 integer will start with a zero byte, which is only correct if the
integer would otherwise be interpreted as negative, i.e. the next byte
starts with the most significant bit set. If that isn't the case, the
encoding is technically invalid and might get rejected by strict parsers.
Note that e49197f15e did not actually fix a violation of RFC 5280 as
asn1_integer() assumes all passed numbers are positive and automatically
adds a zero prefix if the MSB is set. What it did instead (or at least
attempted to) is ensure that the generated serial is a positive 64-bit
number in two's complement. The difference can be seen in the output of
`openssl x509 -text`. While 8-byte serials with the MSB set are printed
as hex dump:
Serial Number:
af:e2:e1:47:0f:66:b5:a4
(The encoding is 02:09:00:af:e2:e1:47:0f:66:b5:a4)
those without MSB set are actually printed as number:
Serial Number: 289805014144645117 (0x405981ffa37f7fd)
(The encoding is 02:08:04:05:98:1F:FA:37:F7:FD)
The reason is that OpenSSL only does the latter if the number fits into a
signed `long` variable, which isn't the case if a positive 64-bit number
has the MSB set (i.e. has a zero prefix) as it would be interpreted as
negative number in two's complement. OpenSSL does print negative serial
numbers (even if it's a violation of the RFC), but only if they were
encoded as such, i.e. if there was no zero prefix:
Serial Number: -5492225205882687294 (-0x4c384db9c7158f3e)
(The encoding is 02:08:b3:c7:b2:46:38:ea:70:c2)
Fixes: e49197f15e ("pki: Don't generate negative random serial numbers in X.509 certificates")
Closesstrongswan/strongswan#631
This is mostly for the non-mmap case as with mmap available, access to the
unmapped memory isn't easily possible (e.g. opening the same area with
MAP_ANONYMOUS | MAP_UNINITIALIZED is usually prevented by the missing
CONFIG_MMAP_ALLOW_UNINITIALIZED option in most kernels).
New versions of Bind limit the maximum UDP message size to 1232 bytes,
which is the same that newer versions of libunbound propose as maximum via
EDNS in requests, so increasing the limit on the server wouldn't help.
Instead we allow DNS via TCP so the client can switch after receiving the
truncated UDP response.
Using the workaround with the EVP interface, which we use to derive shared
keys since 74e02ff5e6 ("openssl: Mainly use EVP interface for ECDH"),
would actually require us to register the OIDs of these curves as NID.
Otherwise, the two EC_GROUPs used by private and public key objects
are not considered the same and the key derivation fails.
Since the curves are supported by OpenSSL since 1.0.2 it's probably rare to
find a version without them nowadays. One exception is the old BoringSSL
version we still use on Android, which defines the NIDs but not the curve
data. However, that version also lacks support to register OIDs as NIDs,
so the only option to support these groups there would be to got back to not
using the EVP interface, which isn't in anyone's interest. If there really
is a need for them there, we could probably patch BoringSSL or use OpenSSL.
The "openssl" alias now defaults to OpenSSL 3.0, which produces a lot of
deprecation warnings. To avoid build failures due to `-Werror`, stay with
OpenSSL 1.1 until we can get rid of these issues.
Tobias Brunner