Incorrect signature verification
An incorrect check of return values in the signature validation utilities allows an attacker to get invalid signatures accepted as valid by forcing an error during validation.
HTTPRedirect class of the SAML2 library has a method called
validateSignature() that allows the verification of
the XML digital signature of a SAML 2 message with a given key. This method uses the
verifySignature() method from
XMLSecurityKey class to verify the signature with the given key, which in turn will
end up calling
openssl_verify() depending on the signature algorithm used.
openssl_verify() function returns
1 when the signature was successfully verified,
0 if it failed to verify
with the given key, and
-1 in case an error occurs. PHP allows translating numerical values to boolean implicitly,
with the following correspondences:
- Non-zero equals
This means that an implicit conversion to boolean of the values returned by
openssl_verify() will convert an error
state, signaled by the value
-1, to a successful verification of the signature (represented by the boolean
The aforementioned method was performing an implicit conversion to boolean of the values returned
verifySignature() method, which subsequently will return the same output as
openssl_verify() under most
circumstances. This means an error during signature verification is treated as a successful verification by the method.
All simplesamlphp/saml2 versions 0.x, 1.x, 2.x and 3.x are affected, up to (including) 1.10.5, 2.3.7 and 3.1.3.
All SimpleSAMLphp versions are affected, up to (including) 1.15.3.
Upon successful exploitation, an invalid signature would be regarded as valid by an affected version of the software. This allows attackers to modify or manually craft SAML 2 messages and, by triggering a signature validation error in the affected party, get those messages accepted as valid and coming from a trusted entity. In practice, this means full capabilities to impersonate any individual at a given service provider.
The issue can be exploited to get other invalid messages accepted as valid, though the security implications there are minor.
In order to exploit the issue, SAML 2 metadata must be registered by the vulnerable Service Provider for the
Identity Provider targeted by the attacker (in
metadata/shib20-idp-remote.php), and an incorrect context must be fed
to the signature validation routines, or an exceptional error must be triggered. So far, the following cases have been
- Using a DSA public key to validate an XML signature made with an RSA-related algorithm.
- Using an RSA public key to validate an XML signature made with a DSA-related algorithm.
- Exhausting available memory while verifying the signature.
SimpleSAMLphp supports only RSA signatures and keys. Therefore, it is not possible for an attacker to feed an incorrect context by sending a signature with an incorrect algorithm. Upon reception of a DSA-SHA1 signature, SimpleSAMLphp will refuse to perform the validation due to the algorithm not being supported. On the other hand, if an attacker manages to trick a service provider operator to change the public key associated to a certain IdP to a DSA key, signatures made with any combination of the RSA algorithm will be accepted, regardless of whether they are valid or not. This means some serious misconfiguration or social engineering is needed in this case for a successful attack.
Regarding memory exhaustion, it is in theory possible to attack a service provider causing the consumption of all available memory while a message with an invalid signature is being validated. However, memory exhaustion must happen only during signature validation and not immediately before or after. This means exploitation of this case is extremely difficult due to the small time window available for the attacker and the precise control that is needed over the service provider.
All in all, the consequences of this issue are critical, so even though we consider it difficult to exploit, and considering that other ways to trigger failures in signature validation could be possible but so far unidentified, we recommend updating the affected software as soon as possible.
Upgrade to the latest versions of the SAML2 library.
For SimpleSAMLphp users, run
composer update or upgrade to SimpleSAMLphp 1.15.4.Refer to the documentation for
instructions on how to run composer.
This security issue was discovered during a security audit performed by Cure53 and reported on December 18, 2017. Later on, after the release of version 1.15.3, John Maguire and Adam Goodman of Duo Security discovered and reported the same issue.