Shibboleth Service Provider Security Advisory [4 May 2016]

Brown, Sam sbrown at
Wed May 4 11:53:44 EDT 2016

Just to clarify.  If the <PathRegex> feature is not in shibboleth2.xml, should it be added with add ignoreCase="false"?  I wasn't sure.

Sam Brown
UCLA Arthur Ashe Student Health & Wellness Center
IT Manager
(310) 206-6356

-----Original Message-----
From: announce [mailto:announce-bounces at] On Behalf Of Cantor, Scott
Sent: Wednesday, May 04, 2016 7:37 AM
To: announce at
Subject: Shibboleth Service Provider Security Advisory [4 May 2016]

Hash: SHA256

Shibboleth Service Provider Security Advisory [4 May 2016]

This issue is rated as "critical", and allows an unauthenticated remote attacker to access protected resources, but it affects only a subset of deployers.

Deployers that do _not_ make use of the <PathRegex> feature are _not_ impacted.

All versions of the Shibboleth SP available are vulnerable to the issue, and deployers should take immediate steps as outlined in this advisory.

Shibboleth SP software <PathRegex> feature implemented incorrectly =======================================================================
The Service Provider software includes a feature to specify protection rules and other settings based on evaluating a regular expression against a portion of the requested URL path. It is used by including a <PathRegex> element in the <RequestMap> construct, typically in the shibboleth2.xml configuration file, and is documented in [1].

This element supports a property named ignoreCase that was meant to default to "true", and would allow for a regular expression to match in a case-insensitive manner (e.g. the path "Foo" would match "foo").

Unfortunately, the property was mistakenly implemented in reverse, and the "true" value was implemented to cause the matching to be case-sensitive. Setting the value to "false" at present results in the intended behavior, while appearing to specify the opposite.

While patching this is extremely simple, creating a situation in which the setting would have the opposite meaning in different versions, and even worse would change its meaning after a patch, was not deemed to be acceptable, and so an alternative plan was developed:

1. Disclose the issue and advise deployers using this feature to change the setting to fix their configurations for the time being.

2. Create a new setting in a small feature update (V2.6.0), likely called "caseSensitive", that would replace use of the original setting. At that point, the ignoreCase setting would be formally deprecated and a warning logged when detected.

There are no known mitigations to prevent this issue apart from applying this workaround.

Check your shibboleth2.xml configuration for the <PathRegex> element.
If used, check for the ignoreCase attribute in the element.

If found, reverse the value (true to false, false to true).

If not found, add ignoreCase="false" to the element.

Restarting the web server will not be required to effect the change.

It is advisable that you create an XML comment near this change to denote the purpose and the confusing value and to revisit it once the new setting is made available to correct the issue.

Note that if following best practices, only IIS and FastCGI deployments would be affected by this issue. Use of Apache commands to supply rules is strongly advised over use of the RequestMap feature, and deployers following that advice are not impacted by this issue. Those using the RequestMap with Apache may wish to revisit that approach, particularly if they are impacted by this issue.

Scott Koranda, Spherical Cow Group


URL for this Security Advisory:

Version: GnuPG v2

To unsubscribe from this list send an email to announce-unsubscribe at

More information about the users mailing list