A potential authorization bypass vulnerability in the gmp plugin was discovered in strongSwan. All versions are affected in certain configurations.
A security researcher and his team found several flaws in the gmp plugin that may lead to an authorization bypass vulnerability. All versions may be affected if the plugin is enabled and low-exponent RSA keys (i.e. with e=3) are in use.
Several flaws in the implementation that parsed and verified RSA signatures in the gmp plugin may allow for Bleichenbacher-style low-exponent signature forgery in certificates and during IKE authentication.
CVE-2018-16151 and CVE-2018-16152 have been assigned for two of the flaws that may lead to this vulnerability (see below for details).
To verify an RSA signature it is decrypted using the public key with the operation me mod n, where m is the signature value, and e and n are the exponent and modulus of the public key, respectively. When using PKCS#1 v1.5 the result of that calculation is a binary number that has a very specific form:
0x00 || 0x01 || PS || 0x00 || T
Where T is an ASN.1 encoded digestInfo (algorithmIdentifier with the OID of the used hash function followed by the binary hash value) and the padding PS consists of at least 8 bytes of 0xFF to make sure the resulting value consists of exactly the same number of bytes as the modulus.
Already in 2006 Daniel Bleichenbacher showed that it is possible to easily forge signatures for low-exponent keys (i.e. with e=3) if an implementation fails to verify that there is enough padding to ensure that T is right-aligned and if it allows arbitrary data after the hash.
While the implementation in the gmp plugin was not vulnerable to the latter (i.e. it didn't allow data after the ASN.1 structure) further research (e.g. in Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures) showed that the ASN.1 structure may offer similar room for variance if the implementation verifying it is not strict enough. Since our ASN.1 parsing code is mainly designed to accept all kinds of keys and certificates etc. it is pretty lenient, which lead to the following issues.
The first is that the OID parser allows any number of random bytes after a valid OID. The asn1_known_oid() function just parses until it finds a leaf in the tree of known OIDs, any further data that follows is simply ignored. And the function that parses ASN.1 algorithmIdentifier structures doesn't care if the full OID data was parsed as it usually doesn't really matter. CVE-2018-16151 has been assigned to this issue.
The second problem is that the algorithmIdentifier structure not only contains the OID but also an optional parameters field. While none of the algorithms used with PKCS#1 use parameters, i.e. the field should always be encoded as ASN.1 NULL value, our parser does not enforce this, it simply skips over the parameters. This allows an attacker to fill the field with random data. CVE-2018-16152 has been assigned to this issue.
Additionally, the implementation did not enforce at least 8 bytes of padding. Actually, it was perfectly fine to accept signatures without any padding at all. This does not immediately lead to a vulnerability in itself (hence no separate CVE is assigned) but it makes exploiting the other flaws much easier.
An attacker may use these flaws to generate forged signatures in order to create arbitrary certificates if a CA certificate uses a low-exponent key, or authenticate as a particular peer if that peer's end-entity certificate or raw public key uses a low-exponent. It's important to note that the attacker does not need to know the actual public key, just the key length (which could be guessed). Such a forged signature will be accepted by any key with the same length and low exponent. More details on exploiting these flaws (the second in particular) may be found in section 5 of the aforementioned paper.
Remote code execution is not possible due to these issues.
Credit to Sze Yiu Chau and his team from Purdue University and The University of Iowa for finding this vulnerability. More details will be released in their research paper later this year.
Since only the gmp plugin is affected, installations that don't have this plugin enabled and loaded are not vulnerable.
If the plugin is loaded, make sure that none of the employed keys and certificates (including those of CAs) use keys with e = 3. Our own tool to generate keys (pki --gen) always used e = 65537 (0x10001), which is not vulnerable, so certificates and keys generated with this tool are fine for use even with an unpatched gmp plugin.
The just released strongSwan 5.7.0 fixes this vulnerability. For older releases we provide patches that fix the vulnerability in the respective versions and should apply with appropriate hunk offsets (please note that patches for versions < 4.4.0 are not provided and that older versions require additional patches).