Shibboleth Identity Provider Security Advisory [UPDATED 25 October 2007]

An updated version of the Shibboleth 1.3 Identity Provider software
is available that partially addresses this issue. Please review the
information below to determine if you're affected and for possible
workarounds for other versions of the software.


Shibboleth IdP software may allow spoofing of AuthenticationMethod
==================================================================

Shibboleth includes the ability to control the value of the SAML
AuthenticationMethod attribute in the assertions it issues based
on an HTTP request header supplied from the Java container. However,
this feature cannot be disabled using the configuration, which means
that most sites, which use a static value in the configuration,
cannot prevent a client from spoofing the header and overriding the
value set in the IdP configuration.

As a result, an SP in general cannot rely on the value unless it
knows that the value is being set in a trustworthy manner that would
not allow for such spoofing to occur.

The AuthenticationInstant value is also spoofable in a similar
manner, but we are not aware of any sites that make use of this
information.

How to tell if you're affected (IdP)
==================================================================

At this time, only an IdP that is ensuring the source header value is
set on every request by a trusted software component, typically
a Java filter or Apache module, can ensure that the value is set
safely.

If you are statically setting a defaultAuthMethod in the idp.xml
file (and you actually care what it is), then you are vulnerable.
(If you don't set it, the default method is simply set to a SAML
value meaning "unspecified", but you're still vulnerable to
spoofing if you actually mean for it to have that value.)

If you are dynamically setting the SAMLAuthenticationMethod header,
but do not set it on every possible request to the IdP servlet, then
you are vulnerable.

The same is true for the SAMLAuthenticationInstant header.

How to tell if you're affected (SP)
==================================================================

As an SP, you only need to be concerned about this issue if you are
relying on the Shib-Authentication-Method value (typically accessed
now as HTTP_SHIB_AUTHENTICATION_METHOD) for some application-specific
purpose. If you do, you should contact IdPs you care about to determine
how the value is being set and find out if it can be trusted or not.

(Note that as of the time of this advisory, we are not aware of
significant/broad use of this feature.)

The AuthenticationInstant information is currently not exposed in a
standard way to applications by the SP software, so unless you are
directly accessing the underlying SAML to examine this attribute,
you are not affected by that aspect of the problem.

Recommendations
---------------

An updated release, 1.3.3, is now available. Sites relying on this
feature should upgrade and review the material below to understand
how to safely deploy it.

Deployers using version 1.2 should assess their vulnerability, and
may need to take steps to protect the header from external spoofing,
and should consider upgrading.

The Apache mod_header module MAY be a way of blocking (or safely
setting) headers, but this has not been investigated. Header
spoofing is complex, and prevention requires knowledge of the
steps that occur during server processing and a determination as
to whether a given solution is comprehensive.

One way known to work is to install a Java filter into Tomcat
that traps requests for a header from the IdP servlet and
always returns null or a fixed value. A filter that you could use
for this is available in the Shibboleth svn repository here:

http://tinyurl.com/2b3cto

https://svn.middleware.georgetown.edu/java-idp/branches/Rel_1_3/src/edu/internet2/middleware/shibboleth/utils/RoleToAuthnMethodFilter.java

It can be used with or without the updated release to assist
with setting this header dynamically, but if used in a simple fashion,
it will simply block all use of the header, preventing any spoof attempt.

A similar mechanism can be used to protect the SAMLAuthenticationInstant
header, although this may not be shown in the example.

Feature Use
-----------

The new 1.3.3 release addresses this spoofing problem in several ways:

- by disabling the use of the SAMLAuthenticationMethod header by default

- by requiring explicit use of the authMethodHeaderName property in idp.xml
  to re-enable it, and to allow for any header name to be used
  
- by providing a Java filter to demonstrate a possible approach to safely
  using this feature

The filter, called RoleToAuthnMethodFilter, ensures that the value of the
"SAMLAuthenticationMethod" header will be returned as null, unless a mapping
of servlet role to method string is provided to the filter. This is merely
an example of what might be done, and the specifics will depend on the
deployment, but some kind of similar protection is required.

The SAMLAuthenticationInstant header was not identified as a problem
during the preparation of this release, but can be addressed using some
of the same tools.

Credits
-------
Thanks to Scott Cantor for reporting and working on this problem.

Thanks also to Tom Scavo for noting the use of
SAMLAuthenticationInstant.

URL for this Security Advisory:
http://shibboleth.internet2.edu/secadv/secadv_20071023.txt