Log injection in SimpleSAMLphp before version 1.18.4. The www/erroreport.php script, which receives error reports and sends them via email to the system administrator, did not properly sanitize the report identifier obtained from the request. This allows an attacker, under specific circumstances, to inject new log lines by manually crafting this report ID. When configured to use the file logging handler, SimpleSAMLphp will output all its logs by appending each log line to a given file. Since the reportID parameter received in a request sent to www/errorreport.php was not properly sanitized, it was possible to inject newline characters into it, effectively allowing a malicious user to inject new log lines with arbitrary content.

Cross-site scripting in SimpleSAMLphp before version 1.18.4. The www/erroreport.php script allows error reports to be submitted and sent to the system administrator. Starting with SimpleSAMLphp 1.18.0, a new SimpleSAML\Utils\EMail class was introduced to handle sending emails, implemented as a wrapper of an external dependency. This new wrapper allows us to use Twig templates in order to create the email sent with an error report. Since Twig provides automatic escaping of variables, manual escaping of the free-text field in www/errorreport.php was removed to avoid double escaping. However, for those not using the new user interface yet, an email template is hardcoded into the class itself in plain PHP. Since no escaping is provided in this template, it is then possible to inject HTML inside the template by manually crafting the contents of the free-text field.

Incorrect signature validation

Open redirection protection bypass

Information leakage issue in the sanitycheck module

Incorrect signature verification

UNSUPPORTED WHEN ASSIGNED A vulnerability was found in simplesamlphp simplesamlphp-module-openidprovider up to 0.8.x. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file templates/trust.tpl.php. The manipulation of the argument StateID leads to cross site scripting. The attack can be launched remotely. Upgrading to version 0.9.0 is able to address this issue. The identifier of the patch is 8365d48c863cf06ccf1465cc0a161cefae29d69d. It is recommended to upgrade the affected component. The identifier VDB-218473 was assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Impact When a response is processed, the issuer of the Identity Provider is not sufficiently validated. This could allow a malicious identity provider to craft a Saml2 response that is processed as if issued by another identity provider. It is also possible for a malicious end user to cause stored state intended for one identity provider to be used when processing the response from another provider.

An application is impacted if they rely on any of these features in their authentication/authorization logic: the issuer of the generated identity and claims items in the stored request state (AuthenticationProperties)

Patches Patched in version 2.9.2 and 1.0.3. All previous versions are vulnerable.

Workarounds The AcsCommandResultCreated notification can be used to add the validation required if an upgrade to patched packages is not possible.

References The patch is linked to https://github.com/Sustainsys/Saml2/issues/712 and https://github.com/Sustainsys/Saml2/issues/713

UNSUPPORTED WHEN ASSIGNED A vulnerability classified as problematic has been found in SimpleSAMLphp simplesamlphp-module-openid. Affected is an unknown function of the file templates/consumer.php of the component OpenID Handler. The manipulation of the argument AuthState leads to cross site scripting. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. Upgrading to version 1.0 is able to address this issue. The patch is identified as d652d41ccaf8c45d5707e741c0c5d82a2365a9a3. It is recommended to upgrade the affected component. VDB-217170 is the identifier assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

A vulnerability was found in Information Cards Module and classified as problematic. This issue affects some unknown processing. The manipulation leads to cross site scripting. The attack may be initiated remotely. Upgrading to version 1.0 is able to address this issue. The name of the patch is f6bfea49ae16dc6e179df8306d39c3694f1ef186. It is recommended to upgrade the affected component. The identifier VDB-217661 was assigned to this vulnerability.

Cross-site scripting (XSS) vulnerability in logout.php in SimpleSAMLphp 1.8.1 and possibly other versions before 1.8.2 allows remote attackers to inject arbitrary web script or HTML via the linkhref parameter.

Cross-site scripting (XSS) vulnerability in modules/core/www/nocookie.php in SimpleSAMLphp 1.8.1 and possibly other versions before 1.8.2 allows remote attackers to inject arbitrary web script or HTML via the retryURL parameter.

A signature-validation bypass issue was discovered in SimpleSAMLphp through 1.14.16. A SimpleSAMLphp Service Provider using SAML 1.1 will regard as valid any unsigned SAML response containing more than one signed assertion, provided that the signature of at least one of the assertions is valid. Attributes contained in all the assertions received will be merged and the entityID of the first assertion received will be used, allowing an attacker to impersonate any user of any IdP given an assertion signed by the targeted IdP.

Cross Site Scripting (XSS) in the consentAdmin module

SimpleSAMLphp 1.14.12 and earlier make it easier for man-in-the-middle attackers to obtain sensitive information by leveraging use of the aesEncrypt and aesDecrypt methods in the SimpleSAML/Utils/Crypto class to protect session identifiers in replies to non-HTTPS service providers.

Multiple timing side-channel issues

Background When a SimpleSAMLphp Identity Provider is misconfigured, a bug in the software when trying to build a persistent NameID to univocally identify the authenticating subject could cause different users to get the same identifier generated, depending on the attributes available for them right after authentication.

Please note that even though this is possible thanks to a bug, an IdP must be misconfigured to release persistent NameIDs even if it is not properly configured to generate them based on the specifics of the deployment.

Description Persistent NameIDs will typically be sent as part of the Subject element of a SAML assertion, or as the contents of the eduPersonTargetedID attribute. Here is an example of such a NameID:

<NameID Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:persistent“> zbonsm0Yn9Gnw14uQEEPr6AO7d+IvxwCQN3t+o24jYs= </NameID>

Some service providers will use this information to identify a user across sessions because a persistent NameID will never change for a given user. This could lead to different users accessing the same account in those service providers.

In order to be affected by this issue, the following circumstances must concur:

- SimpleSAMLphp acts as an identity provider. - The service provider asking for authentication requests a persistent NameID. - No saml:PersistentNameID authentication processing filter is configured (neither for the whole IdP, nor for a given SP). - No simplesaml.nameidattribute configuration option is set (neither for the whole IdP, nor for a given SP). - One of the following alternatives: - No userid.attribute configuration option is set and the users don't have an eduPersonPrincipalName attribute in the users backend, or - the userid.attribute configuration option is set to an empty or missing attribute.

If all these requirements are met, the SimpleSAMLAuthProcessingChain class will try to keep a unique user identifier in the state array (addUserID() method). Bear in mind that this code is executed before all the authentication processing filters configured, meaning that only those attributes retrieved for the user during initial authentication will be available. If no userid.attribute configuration option is set, the default eduPersonPrincipalName will then be used. However, since it is missing, no identifier will be kept. Alternatively, if userid.attribute is set to a missing or empty attribute, the addUserID() method will abort trying to register an identifier.

After executing all authentication processing filters, SimpleSAMLphp will build a SAML assertion. If the service provider requests persistent NameIDs, SimpleSAMLphp will attempt to generate one given that none is already available (because the saml:PersistentNameID filter was not used). At this point, the code will look for the simplesaml.nameidattribute configuration option in either the local IdP metadata or in the remote SP metadata. If none of them are configured, it will default to the unique user identifier previously registered by SimpleSAMLAuthProcessingChain. If no identifier was kept there, the code will log an error message:

Unable to generate NameID. Check the userid.attribute option.

However, instead of aborting the NameID generation at that point, it will go on and use a value missing from the state array as the source for the computation, meaning the null type will be used. Hence, all users connecting to a given service provider will get the same NameID generated, because all the input parameters will be the same:

- The SP's entity identifier. - The IdP's entity identifier. - The null value. - The common secret salt from the main configuration.

Affected versions All SimpleSAMLphp versions between 1.7.0 and 1.14.10, inclusive.

Impact Those identity providers affected by this bug and misconfigured as previously described could be issuing SAML assertions with common NameIDs for all or a subset of their users. If a service provider uses those NameIDs to identify the users of the affected IdP, all the users will be associated with the same user account at the service provider, causing all sorts of potential security issues like information disclosure or unauthorized access.

While we can consider this unlikely to happen, some cases have been already observed. In particular, some identity providers using default configurations and consuming metadata automatically (i.e. using the metarefresh module) while using a user backend like Active Directory that does not populate eduPersonPrincipalName are particularly sensitive to this issue.

Resolution Upgrade to the latest version.

Configure a saml:PersistentNameID authentication processing filter according to your needs. Remember to check that the attribute used as the source for the NameID is present at the moment the saml:PersistentNameID filter is executed. The attribute used must be unique per user, and must not change over time.

Authentication context bypass (multiauth module)

Invalid token creation and validation

Session fixation and authentication bypass (authcrypt module)

Incorrect IV generation for encryption

Critical signature bypass

Background

The module controller in SimpleSAML\Module that processes requests for pages hosted by modules, has code to identify paths ending with .php and process those as PHP code. If no other suitable way of handling the given path exists it presents the file to the browser.

Description

The check to identify paths ending with .php does not account for uppercase letters. If someone requests a path ending with e.g. .PHP and the server is serving the code from a case-insensitive file system, such as on Windows, the processing of the PHP code does not occur, and the source code is instead presented to the browser.

Affected versions

SimpleSAMLphp versions 1.18.5 and older.

Impact

An attacker may use this issue to gain access to the source code in third-party modules that is meant to be private, or even sensitive. However, the attack surface is considered small, as the attack will only work when SimpleSAMLphp serves such content from a file system that is not case-sensitive, such as on Windows.

Resolution

Upgrade the SimpleSAMLphp installation to version 1.18.6.

Credit

This vulnerability was discovered and reported by Sławek Naczyński.

Validation of an XML Signature requires verification that the hash value of the related XML-document (after any optional transformations and/or normalizations) matches a specific DigestValue-value, but also that the cryptografic signature on the SignedInfo-tree (the one that contains the DigestValue) verifies and matches a trusted public key.

Within the simpleSAMLphp/xml-security library (https://github.com/simplesamlphp/xml-security), the hash is being validated using SignedElementTrait::validateReference, and the signature is being verified in SignedElementTrait::verifyInternal

https://github.com/simplesamlphp/xml-security/blob/master/src/XML/SignedElementTrait.php:

!afbeelding

What stands out is that the signature is being calculated over the canonical version of the SignedInfo-tree. The validateReference method, however, uses the original non-canonicalized version of SignedInfo.

Impact If an attacker somehow (i.e. by exploiting a bug in PHP's canonicalization function) manages to manipulate the canonicalized version's DigestValue, it would be potentially be possible to forge the signature. No possibilities to exploit this were found during the investigation.