Created attachment 861556 [details]
Attached patch

Dear strongSwan partner,

Lahav Schlesinger reported a bug related to online certificate revocation checking that can lead to a denial-of-service attack.


# Using Untrusted URIs for Revocation Checking

Because the revocation plugin uses potentially untrusted OCSP URIs and CRL distribution points (CDP) in certificates, a remote attacker is able to initiate IKE_SAs and send crafted certificates that contain URIs pointing to servers under their control, which can lead to a denial-of-service attack.  Affected are all strongSwan versions, including the latest 5.9.7.

CVE-2022-40617 has been assigned for this vulnerability.


## Problematic Inline Revocation Checking in Trust Chain Validation

strongSwan's credential manager component, which is responsible for verifying trust chains, always did online certificate revocation checks inline while traversing the certificate chain.  That is, for each certificate, starting with the end-entity certificate, it searches a matching issuer certificate and if the signature and lifetimes are valid, calls plugins via the cert_validator_t interface to do extended validation of the current certificate.  One of these plugins is the revocation plugin that uses OCSP URIs and CDPs in the issued certificate to check its status (e.g. whether it was revoked by the issuing CA).

While this approach allows to immediately abort the validation if a revoked certificate is encountered, the problem is that the certificate chain might not yet be trusted when the revocation plugin accesses the contained URIs.  Only for a single-level PKI is the trust immediately established when finding the trusted, self-signed CA certificate that issued the end-entity certificate.  So if an attacker sends specifically crafted end-entity and intermediate CA certificates, the URIs in the end-entity certificate are used for online revocation checks before the intermediate CA certificate is later rejected because no trusted issuer certificate is found and the authentication fails.

This allows attackers to encode URIs to servers under their control and force a strongSwan instance to connect to them.


## Denial-of-Service Due To Attacker-Controlled OCSP URIs and CDPs

As described above, attackers are able force the revocation plugin to make requests to arbitrary servers.  This can lead to different kinds of denial-of-service attacks, depending on how these servers react.

A first one can be caused via a server that lets clients complete the TCP three-way handshake but then sends no data.  It has to be reachable as there is an initial connection timeout (for DNS resolution and TCP handshake completion).  But because the revocation plugin does not set an overall timeout for its requests and some fetcher plugins don't use one by default, in particular the commonly used curl plugin, the worker thread will be blocked practically indefinitely (i.e. until the default TCP timeout of the underling TCP/IP stack).  By initiating multiple IKE_SAs with the same certificates, attackers are able to block worker threads to the point the daemon will not be able to process any further IKE messages or other events.

In a second potential attack, instead of sending no data, the server sends a lot of it.  Because the fetched OCSP/CRL data is stored in memory and without any upper limits, the attacker might be able to exhaust all memory of the host strongSwan runs on, or at least force a system like Linux's OOM killer to terminate the IKE daemon.

Remote code execution is not possible due to this issue.


# Mitigation

Setups that don't use the revocation plugin are not directly vulnerable.  However, if custom plugins are loaded that implement the validate() method of the cert_validator_t interface, there could be similar problems due to the inline certificate validation described above.

The attached patch fixes the vulnerability in the affected strongSwan versions by creating a trusted certificate chain before starting online revocation checks and should apply with appropriate hunk offsets (please note that patches for versions < 5.1.0 are not provided).

Please prepare updated releases and patch your installations, but do not yet publicly disclose any information about the vulnerability.  We want to give you as a partner enough time to prepare new releases and will publicly disclose the vulnerability with the strongSwan 5.9.8 release on Mon Oct 3, 14:00 CEST.

As mentioned in the introduction, credit to Lahav Schlesinger for finding this vulnerability.

Our apologies for the inconvenience.

Kind Regards
Tobias Brunner
strongSwan Developer