src/scepclient/scepclient.8 | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix typo in ipsec-scepclient(8) manpage name

conf/plugins/bypass-lan.conf | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 don't load bypass-lan plugin by default

init/systemd-starter/strongswan-starter.service.in | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 tune the ipsec systemd service file

- add a reload argument
- don't wait on syslog

src/libtls/Makefile.am | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 disable libtls tests

They're too intensive for the buildd network and cause FTBFS

conf/plugins/kernel-libipsec.conf | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 dont-load-kernel-libipsec-plugin-by-default

src/libstrongswan/credentials/sets/cert_cache.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 cert-cache: prevent crash due to integer overflow/sign change

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: 764e8b2211ce ("reimplemented certificate cache")
Fixes: CVE-2021-41991

src/libstrongswan/credentials/keys/signature_params.c | 6 5 + 1 - 0 !
src/libstrongswan/plugins/gmp/gmp_rsa_public_key.c | 2 1 + 1 - 0 !
2 files changed, 6 insertions(+), 2 deletions(-)

 reject rsassa-pss params with negative salt length

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.

Not checking this could lead to an integer overflow.  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: a22316520b91 ("signature-params: Add functions to parse/build ASN.1 RSASSA-PSS params")
Fixes: 7d6b81648b2d ("gmp: Add support for RSASSA-PSS signature verification")
Fixes: CVE-2021-41990

src/libcharon/plugins/eap_gtc/eap_gtc.c | 2 1 + 1 - 0 !
src/libcharon/plugins/eap_md5/eap_md5.c | 2 1 + 1 - 0 !
src/libcharon/plugins/eap_radius/eap_radius.c | 4 3 + 1 - 0 !
src/libcharon/sa/eap/eap_method.h | 8 7 + 1 - 0 !
src/libcharon/sa/ikev2/authenticators/eap_authenticator.c | 32 28 + 4 - 0 !
5 files changed, 40 insertions(+), 8 deletions(-)

 eap-authenticator: enforce failure if msk generation fails

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: 0706c39cda52 ("added support for EAP methods not establishing an MSK")
Fixes: CVE-2021-45079

src/libstrongswan/credentials/credential_manager.c | 54 45 + 9 - 0 !
1 file changed, 45 insertions(+), 9 deletions(-)

 credential-manager: do online revocation checks only after basic
 trust chain validation

This avoids querying URLs of potentially untrusted certificates, e.g. if
an attacker sends a specially crafted end-entity and intermediate CA
certificate with a CDP that points to a server that completes the
TCP handshake but then does not send any further data, which will block
the fetcher thread (depending on the plugin) for as long as the default
timeout for TCP.  Doing that multiple times will block all worker threads,
leading to a DoS attack.

The logging during the certificate verification obviously changes.  The
following example shows the output of `pki --verify` for the current
strongswan.org certificate:

new:

  using certificate "CN=www.strongswan.org"
  using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=R3"
  using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
  reached self-signed root ca with a path length of 1
checking certificate status of "CN=www.strongswan.org"
  requesting ocsp status from 'http://r3.o.lencr.org' ...
  ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
  ocsp response is valid: until Jul 27 12:59:58 2022
certificate status is good
checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=R3' found
  fetching crl from 'http://x1.c.lencr.org/' ...
  using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
  crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
  crl is valid: until Apr 18 01:59:59 2023
certificate status is good
certificate trusted, lifetimes valid, certificate not revoked

old:

  using certificate "CN=www.strongswan.org"
  using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=R3"
checking certificate status of "CN=www.strongswan.org"
  requesting ocsp status from 'http://r3.o.lencr.org' ...
  ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
  ocsp response is valid: until Jul 27 12:59:58 2022
certificate status is good
  using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=R3' found
  fetching crl from 'http://x1.c.lencr.org/' ...
  using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
  crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
  crl is valid: until Apr 18 01:59:59 2023
certificate status is good
  reached self-signed root ca with a path length of 1
certificate trusted, lifetimes valid, certificate not revoked

Note that this also fixes an issue with the previous dual-use of the
`trusted` flag.  It not only indicated whether the chain is trusted but
also whether the current issuer is the root anchor (the corresponding
flag in the `cert_validator_t` interface is called `anchor`).  This is
was problem when building multi-level trust chains for pre-trusted
end-entity certificates (i.e. where `trusted` is TRUE from the start).
This caused the main loop to get aborted after the first intermediate CA
certificate and the mentioned `anchor` flag wasn't correct in any calls
to `cert_validator_t` implementations.

src/charon-tkm/src/tkm/tkm_diffie_hellman.c | 7 6 + 1 - 0 !
1 file changed, 6 insertions(+), 1 deletion(-)

 charon-tkm: validate dh public key to fix potential buffer overflow

Seems this was forgotten in the referenced commit and actually could lead
to a buffer overflow.  Since charon-tkm is untrusted this isn't that
much of an issue but could at least be easily exploited for a DoS attack
as DH public values are set when handling IKE_SA_INIT requests.