Shibboleth Service Provider Security Advisory [15 June 2009]

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

Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
Shibboleth Service Provider Security Advisory [15 June 2009]

Updated versions of the Shibboleth 1.3.x and 2.x Service Provider
software are now available which correct a security issue.

This advisory pertains ONLY to sites running the SP software in
conjunction with Microsoft's Internet Information Server (IIS)
web server. All IIS and Windows versions are believed to be affected,
primarily in conjunction with ASP.NET applications. While classic ASP
and some other development tools are believed near-term safe, all IIS
deployers should review this advisory and take appropriate steps.

There are no known issues affecting non-IIS deployments, including
all non-Windows deployments, and Apache on Windows.

This is a MAJOR security issue and deployers are urged to review
the information below and upgrade their installations at the soonest
possible time. Critical applications that may be vulnerable should be
taken offline until the upgrade is performed.

Shibboleth SP software on IIS vulnerable to header spoofing
On IIS, Shibboleth publishes user attributes associated with
sessions into HTTP request headers, based on header names defined
in Attribute Acceptance Policy (1.3.x) or Attribute Mapping (2.x)
files. These headers are transformed into CGI variables based
on mapping rules defined by the CGI specification. A number of
built-in headers are set by the SP as well.

The mapping between headers and CGI variables is not exact, and there
are multiple header names that can map to the same variable. IIS in
particular handles underscores and hyphens in header names in an
unusual and problematic way, and behaves differently with respect
to ASP.NET scripts than with classic ASP and other tested languages.

The code in Shibboleth that is designed to clear out the potential
headers that could contain authentication and attribute information
cannot handle the underscore/hyphen distinction efficiently and
cannot protect against such spoofing for the affected ASP.NET

This means that a client could supply a spoofed header with the
right name and fool an application into believing that the header
was set by the Shibboleth software.

All versions of Shibboleth used with IIS are vulnerable to this issue
when an affected application language is used. At this time, only ASP.NET
is known to be affected, but it's likely that others may be affected now
or in the future.

However, the specific headers affected are ONLY those containing either
a hyphen or an underscore (not including the leading underscore following
the HTTP prefix).

For example, the built-in header "HTTP_SHIB_IDENTITY_PROVIDER" *is*
vulnerable, but a mapped header name of "HTTP_GIVENNAME" would *not* be.


Because this is a complex issue, and there are a variety of work-arounds
both pre- and post-update, please refer to this wiki topic for detailed
information on assessing vulnerability and the trade-offs of various

This should address most questions and provide advice on both short-term
and longer-term measures, including safe coding practices. If in doubt,
feel free to contact the support list, or if you require confidential
advice, feel free to use the "security reporting form" at

As a general recommendation:

Affected sites using 1.3.x should upgrade to the latest patched release,

Affected sites using 2.x should upgrade to the latest patched release,

Having done so, you will have a measure of protection while researching
your exposure to the problem and how to address it. But this is NOT a
complete fix and deployers are urged to review the topic above to fully
address the issue. It is likely that the new "safeHeaderNames" option will
need to be enabled (it is on by default in new installations) and that
applications hosted on IIS will require changes in the header names they
are accessing to completely address the problem.

As only Windows sites are affected in a security sense, note that the
simplest way to patch is with the post-install ZIP archives available
from the official download site. Updated installers are also available.

At the time of writing, RPMs and other package formats may not yet be
available, since the urgency of the update is a Windows-only issue.
Source tarballs will however be posted, and other official packages will
follow as time permits.

URL for this Security Advisory: