Configuration (in settings.php) information disclosure

Bug / vulnerability

From versions 8.x-3.0-rc1 until 8.x-3.5, the configuration form(s) for this module also display settings which are hardcoded in Drupal's settings.php or similar configuration files.

This means that these hardcoded settings can get saved in the database, and become part of exported configuration files.

Of particular note: the private key (if configured as part of settings.php) could leak into the exported configuration and be inadvertently distributed to non-private storage.

Nature of vulnerability

In most SAML configurations, leakage of the private key can be seen as not-exploitable, because of other independent layers of security measures. See below for details.

The Drupal security team concluded this issue does not need a Security Announcement.

Fixing the vulnerability

Unless the "Assesing ..." section gives no reason to do so:

• Upgrade the samlauth module to version 8.x-3.6 or higher.
• Install a new private key if desired.
• Compare exported configuration and/or values still visible in the configuration screen, with the configuration hardcoded in settings.php. Any values present in settings.php which are also found in exported files / the screen, can be emptied out and re-exported if desired.
• Trace and delete any database backup and / or exported configuration files that contain 'compromised' settings, if these are still considered a risk after renewing the private key / other settings.

Assessing the vulnerability's scope in your situation

1) Do you store samlauth configuration settings in code (e.g. settings.php), and are these considered 'compromised' when they are spread?

If no, your application is not compromised (and upgrading the module is optional).

2) Has the samlauth configuration screen ever been saved manually?

If no, your application is not compromised (but upgrading the module is recommended, to harden against this happening in the future).

If yes, settings from your settings.php are saved in the Drupal database.

(For multi-site installations where individual sites using this module are deployed automatically, the answer is likely "no" for those sites.)

3) Is your SP private key stored as type "configuration", as opposed to "file" or "key"? (I.e. is the key value itself stored in configuration, rather than the filename?)

If yes, your private key can be considered compromised; read on to see what this means. If no, it is not - but check point 6.

4a) Does your Identity Provider configure a list of registered SPs with their assigned URLs, and does it disallow redirecting to any unconfigured URLs?

4b) Does your Identity Provider encrypt SAML responses sent back to the SP?

If 4a = yes, your system is not vulnerable to this point. (Basically, a compromised private key is not susceptible to malicious use for SAML related purposes.)

If 4a = no AND 4b = "yes", the compromised private key can be used for information harvesting - an attacker could set up an SP endpoint on a different domain, trick people into logging into there and harvest details sent in the SAML responses. You should renew the private key.

If 4a = no AND 4b = "no", you were already vulnerable to this kind of information harvesting so the compromised private key does not constitute a new attack vector.

(It is expected that 4a = yes for all commercial Identity Providers. If you have set up your own Identity Provider using e.g. SimpleSamlPHP, it is possible to configure it so that 4a = no, but it seems unlikely for 4b to be "yes" at the same time.)

5) Is the same private key that is used by samlauth / the SP, used anywhere else?

If yes, replace this key everywhere.

6) Is there any other configuration information stored in settings.php, besides the private key, which you consider private? (e.g. the SP entity ID)

If yes, then

• where possible, replace them by other values.
• where not possible, it will be necessary to trace the reach of database backups and exported configuration files, and remove them.

Miscellaneous

For Acquia Cloud Site Factory, the answer to 4a is "yes" and the answer to 1, to the best of my knowledge, is "(yes, and) no".