Incorrect signature verification in SimpleSAMLphp

Background

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.

Description

The SimpleSAML_XML_Validator class allows the verification of the XML digital signature of a SAML 1 message with a given key. In particular, the constructor of the class receives an XML node and a key to verify it and throws an exception in case there is an error, either caused by incorrect input or an invalid signature. This method uses the verify() method from the RobRichards\XMLSecDSig class to verify the signature with the given key, which in turn will end up calling openssl_verify() depending on the signature algorithm used.

The 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:

• 0 equals false
• Non-zero equals true

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 successful verification of the signature (represented by the boolean true).

The aforementioned constructor was performing an implicit conversion to boolean of the values returned by the verify() 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.

Affected versions

All SimpleSAMLphp versions prior to 1.14.11.

Impact

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 1 response 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 1.1 metadata must be registered by the vulnerable Service Provider for the Identity Provider targeted by the attacker (in ), 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 identified: