
=====================================================================

                                 CERT-Renater

                      Note d'Information No. 2022/VULN386

_____________________________________________________________________

DATE                : 14/10/2022

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running strongSwan versions prior to
                                        5.9.8.

=====================================================================
https://www.strongswan.org/blog/2022/10/03/strongswan-vulnerability-(cve-2022-40617).html
_____________________________________________________________________

strongSwan Vulnerability (CVE-2022-40617)
Posted on Oct 03, 2022 by tobias  | Tags: security fix, 5.9.x, 5.8.x,
5.7.x, 5.6.x, 5.5.x, 5.4.x, 5.3.x, 5.2.x, 5.1.x, 5.0.x, 4.x

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.

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
if they use the revocation plugin or a custom plugin that implements
similar features.

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 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.


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 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).


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================


