Notwithstanding the information that follows, it is suggested that all IIS installations upgrade to the latest SP version as soon as possible. For sites still using 1.3.1, please apply the latest 1.3.x update immediately, and then begin planning your upgrade to 2.x or make other arrangements.

Upgrading within a release branch is straightforward, and takes just a few minutes.

Upgrading Help

Affected Configurations

The vulnerabilities discovered, addressed in versions 2.2+ and 1.3.2+, affect only Internet Information Server (IIS) installations.

All other web servers and platforms are unaffected when using earlier versions (2.1 and 1.3.1), but you may wish to review the information later in this topic for information about how spoofing is prevented and how to supplement that protection across all platforms.

How can I tell if I'm affected?

Short version:

Any ASP.NET application using the System.Web.HttpRequest.ServerVariables collection, and relying on header variables set by the SP that contain underscores, with the exception of the first underscore following "HTTP" in the header name. "HTTP_FOO_BAR" is a problem, while "HTTP_FOOBAR" is not. Note that the shorthand syntax of Request("HTTP_VARIABLE_NAME") is equivalent to using that collection, and is affected.

Longer explanation:

At the time of writing, the only definite exposure is to ASP.NET applications using the System.Web.HttpRequest.ServerVariables collection (or the shorthand of Request("HTTP_VARIABLE_NAME")).

Using the System.Web.HttpRequest.Headers collection appears to be unaffected by this vulnerability. If your application is accessing the header variables through that collection with names such as "Shib-Identity-Provider", "remote-user", or "Shib-EP-Affiliation" (with no "HTTP_" prefix), it appears to be safe.

Classic ASP (scripts with the .asp extension rather than .aspx) and other common tools such as Java, Perl, and, Cold Fusion have also not exhibited the same behavior and may not be vulnerable. However, this is subject to change as further testing is performed, and the safest course is to assume that any language could be affected. We strongly suggest that the same update and remediation steps be followed for all IIS-hosted applications at your earliest convenience.

The specific vulnerability involves applications (again, apparently ASP.NET via the ServerVariables collection, for now) that rely on request headers/variables set by the SP that contain underscores in their final "accessible" form.

This caveat generally applies to most Shibboleth-reliant applications today, for several reasons:

The "built-in" headers reflecting generic session details like the identity provider's name, and the time and method of authentication, contain hyphens in their "raw" form, resulting in underscores at access-time. (An example is "HTTP_SHIB_IDENTITY_PROVIDER".)

The ill-advised feature that simulates the ability to use REMOTE_USER on IIS is actually a header called HTTP_REMOTE_USER (which obviously has an underscore in it).

Many default attribute mappings in both 1.3.x and 2.x include hyphens that become underscores (e.g. "HTTP_PERSISTENT_ID" or "HTTP_SHIB-EP-AFFILIATION").

In short, hyphens that become underscores are extremely common and were not really meant to be avoided.

Note that the first underscore (the "HTTP_") separator isn't a factor. A mapping to a header named "HTTP_DISPLAYNAME" is safe, and is NOT affected by the vulnerability.

Is there something I can do before patching my system?

In principle, you could alter your attribute mappings and remediate applications to switch to headers that don't contain underscores, where possible, or switch to the System.Web.HttpRequest.Headers collection using the unprefixed names, but the time it would take to do this is more than the time it will take you to update your software, so this makes little sense as an option, though it's necessary at some point after updating (see below).

What's my situation immediately after updating?

There are two independent considerations once you've applied the update:

Spoof Checking
Header Safety/Remediation

In summary, after updating, most systems will be functioning in a defensive posture that detects and blocks attempts to spoof a header. If you had previously disabled the checkSpoofing SP setting because of false alarms, you will need to re-enable it after the update. If you're running Windows 2000 or earlier, you will need to manually create a spoofKey setting, or the filter will not load (see below).

Your system will remain vulnerable at this stage unless you ensure that no scripts are accessible that would enable the client to see a dump of all the available request headers or obtain the value of one arbitrarily.

After this stage, you will need to proceed in a timely manner to remediate your application to use the System.Web.HttpRequest.Headers collection, or to rely on sanitized header names enabled with the safeHeaderNames option (see below).

Of course, the default settings are now such that a newly installed system will be safe "out of the box". The complexity here arises from backward compatibility considerations and need for remediation.

The following sections, and related topics, address these issues in some detail.

Spoof Checking

Updating can give you a measure of protection against this vulnerability so that you can plan for more complete remediation. The update strengthens a feature called Spoof Checking that was implemented in earlier versions, but had significant flaws and some fatal limitations that made it ineffective.

For complete details on this feature, and how to control it, you can read the Spoof Checking topic. The most significant material for IIS systems is reproduced here.

On most modern versions of Windows, the spoof checking feature is automatically active unless a setting named checkSpoofing is set to false in the <InProcess> configuration element (or <Local> in the case of 1.3.2). Some sites may have manually disabled this feature in the past because of its bugs. You MUST re-enable this setting now by simply removing the setting and letting it enable itself by default.

Windows 2000 and Earlier

On older Windows versions, in addition to the above, you will also need to add a setting to that same configuration element named spoofKey containing a long, random string of characters. Without that setting, your web server will fail to load the filter with an error in the Windows event log.

Preventing Circumvention

A critical limitation of this feature is that it can only protect your site if there are no "debugging" scripts accessible to users that might display internal server variables and headers to the user. Scripts like this are often used in debugging problems by "dumping" the request variables available to applications.

If a user can access such a script, or otherwise obtain the value of an arbitrary request variable set by the SP, the spoof checking feature can be circumvented. Note that blocking or removing such scripts is a standard server-hardening measure that should not be unusual or unfamiliar.

Header Safety/Remediation

While the Spoof Checking feature has been improved, it isn't perfect and is meant to buy time for the more complete solution, which is to convert applications to rely only on "safe" header names that don't contain underscores (excepting the one following "HTTP").

Implementing this change has been facilitated through the addition of a new IIS-specific setting called safeHeaderNames in the <ISAPI> configuration element. It is false when omitted, for compatibility reasons, but as of these new releases, the default configuration includes this setting to ensure proper practice for new installations.

The purpose of this setting is to allow existing attribute mapping configurations to "just work safely" on IIS by automatically stripping out non-alphanumeric characters while exporting header variables. For example, the "HTTP_SHIB_IDENTITY_PROVIDER" variable is automatically converted into "HTTP_SHIBIDENTITYPROVIDER", and "HTTP_REMOTE_USER" becomes "HTTP_REMOTEUSER".

Effective Coding Practices

Obviously, using this setting is only half of the picture, since applications also have to be modified to use the sanitized header names. If you've sensibly created constants in some fashion to easily parameterize the names of the server variables you're reading from, this should be a very simple change to make.

If instead you find yourself searching through code to make this change, consider taking the opportunity to fix your applications to properly isolate these variable names (or even the accesses themselves and save them into per-request data structures) so that you can change them easily in the future.

HELP!

I fully realize this is a complicated situation. I've tried to lay out the set of steps needed as concisely as I can, but I encourage anybody who's concerned about their system to start by applying the update and then feel free to contact the Shibboleth team using the mailing list.

We'll be happy to respond and advise as to your particular situation.

Browser not supported