A denial-of-service vulnerability in the in-memory certificate cache was discovered in strongSwan. All versions since 4.2.10 are affected.
Researchers at the NSA discovered an integer overflow bug in the in-memory certificate cache that may lead to a denial-of-service attack. All versions since 4.2.10 are affected if the cache is enabled (the default).
Once the in-memory certificate cache is full it tries to randomly replace lesser used entries. Depending on the generated random value, this could lead to an integer overflow that results in a double-dereference and a call using out-of-bounds memory that most likely leads to a segmentation fault.
CVE-2021-41991 has been assigned for this vulnerability.
The in-memory certificate cache stores the relationship between a validated certificate and the issuing certificate to improve performance for later validations of the same certificate. It has a limited size of 32 slots (the size is a compile-time constant). Once all of these slots are full, the code tries several times to find a slot that has been used
less or equal than half the average use count of all slots. For each try, it starts the search at a random slot using the following code:
int offset = random();
for (int i = 0; i < 32; i++)
{
rel = &this->relations[(i + offset) % CACHE_SIZE];
if (rel->hits > total_hits / 32)
{
continue;
}
if (rel->lock->try_write_lock(rel->lock))
{
/* replace cache entry */
return;
}
}
The random() function returns a value between 0 and RAND_MAX, where RAND_MAX is usually equaling INT_MAX = 231-1. So if the returned value is very high, the index calculation causes an integer overflow and an out-of-bounds array access at a negative index value. If the hit check is passed, the double-dereference to allocate the lock most likely causes a segmentation fault.
Triggering this bug in a reliable way isn't that easy and requires thousands of requests over roughly a day or two (an attacker could always get lucky before, though). Replacing cache entries in a relatively controlled way also requires exploiting the lenient nature of the x509 plugin's certificate parser, which doesn't enforce that the parameters of the signatureAlgorithm field in the outer Certificate structure of an X.509 certificate are absent or NULL (except for RSASSA-PSS), or compare them to the parameters of the signature field inside the signed tbsCertificate structure. This allows generating infinite versions of a valid certificate without access to the private key by e.g. including random ASN.1 integers in the parameters of the outer signatureAlgorithm field. Since the certificate cache uses binary comparison of the certificate's complete encoding, this allows caching the same certificate multiple times.
Note that strongSwan 5.9.4 includes changes that prevent this, but we don't provide a patch for older releases as it does not pose a security issue in itself.
Remote code execution can't be ruled out completely, but attackers have no control over the dereferenced memory, so it seems unlikely at this point.
As mentioned in the introduction, credit to the researchers at the NSA for finding this vulnerability.
Installations that don't have the in-memory certificate cache enabled are not vulnerable. However, charon.cert_cache is enabled, by default.
The just released strongSwan 5.9.4 fixes this vulnerability. For older releases we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets (please note that patches for versions < 4.4.1 are not provided).