201612-03

Incorrect signature verification

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 InfoCard SimpleSAMLphp module allows incorporates a series of libraries provided by the Zend Framework. As part of this third-party library, the class Zend_InfoCard_Xml_Security allows the verification of the XML digital signature of XML chunks with a given key. In particular, the validateXMLSignature() method receives an string containing an XML document and a key to verify it, and throws an exception in case there is any error, either caused by incorrect input or an invalid signature. This method uses the openssl_verify() function provided by the openssl PHP extension.

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

The aforementioned method was performing an implicit conversion to boolean of the values returned by the openssl_verify() function. This means an error during signature verification is treated as a successful verification by the method.

Affected versions

The InfoCard module version 1.0.

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 XML 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 could mean the capability to access resources while impersonating other individuals, effectively bypassing authentication.

In order to exploit the issue 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:

• 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.

The code allows for both DSA and RSA keys being used. However, a check between the configured key and the one received in the XML message is performed, aborting execution in case a mismatch is detected.

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.

Resolution

Upgrade to the latest version.