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
Currently the length of vendor ID Cisco VPN Concentrator is 16
bytes but the string has only 13+1 bytes. The actual vendor
ID has 16 bytes with a prefix length of 14 bytes and two version
bytes.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
Before commit 6c49ddfbca ("ike: Add additional Vendor IDs for
third-party implementations") the prefix length of vendor ID
Cisco Unity was hardcoded to 14. Since we need to know the actual
length of this VID to send it, the length can't be overloaded
with a prefix length. Revert part of commit 6c49ddfbca to
fix this problem.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
Before commit 6c49ddfbca ("ike: Add additional Vendor IDs for
third-party implementations") the prefix length of vendor ID
MS NT5 ISAKMPOAKLEY was hardcoded to 16. Change the prefix length
accordingly.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
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