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.
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
The commit mentioned below adds an AES-GCM default proposal for ESP. That
proposal does not include any ESN or non-ESN transform to indicate if
extended sequence numbers are supported.
A standards-compliant peer will include one or more ESN support transforms,
and will be unable to select this proposal due to a proposal mismatch.
Fix the default AES-GCM proposal by adding a NO_ESN algorithm. While ESN has
been supported in the Linux kernel for a while, having it in the default
proposal can be problematic with kernel-libipsec or on other platforms.
Fixes: c7bef954ee ("proposal: Add AES-GCM to the ESP default AEAD proposal")
Closesstrongswan/strongswan#868
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
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.
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")
Tobias Brunner