A vulnerability related to online certificate revocation checking was discovered in strongSwan that can lead to a denial-of-service attack. All versions may be affected.
Lahav Schlesinger reported a bug related to online certificate revocation checking that can lead to a denial-of-service attack.
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 if they use the revocation plugin or a custom plugin that implements similar features.
CVE-2022-40617 has been assigned for this vulnerability.
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.
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 doesn't 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.
As mentioned in the introduction, credit to Lahav Schlesinger for finding this vulnerability.
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 just released strongSwan 5.9.8 fixes this vulnerability by creating a trusted certificate chain before starting online revocation checks. For older releases, we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets (please note that we don't provide patches for versions < 5.1.0).