Shibboleth Service Provider Security Advisory [4 May 2016]

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Shibboleth Service Provider Security Advisory [4 May 2016]

Cantor, Scott E.
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_

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

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 [hidden email]