Shibboleth Identity Provider Security Advisory [18 May 2017]

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

Shibboleth Identity Provider Security Advisory [18 May 2017]

Cantor, Scott E.
Hash: SHA256

Shibboleth Identity Provider Security Advisory [18 May 2017]

Default Kerberos configurations are unsafe
The Identity Provider software includes login support for the Java
Kerberos implementation [1], as well as support for JAAS [2], which
also supports the use of Kerberos.

Both approaches require care in configuring your system, and the default
behavior of Java includes behavior that may be unsafe in some scenarios,
warranting this advisory to ensure deployers have taken the appropriate

Deployments that do not make use of one of these features, or which use
the SPNEGO feature, are not impacted by this advisory.

The issue of concern is the support for DNS to locate the KDC server(s)
for a realm dynamically. Usually realm information is statically
configured into a krb5.conf file, but Kerberos defines a mechanism for
the use of DNS SRV records to locate servers. When enabled, a request
for a TGT for a principal name containing a realm (e.g., [hidden email])
can cause a Kerberos implementation to look for the KDC using DNS and
automatically use the result.

This may allow an attacker to successfully supply an unexpected username
and password to an IdP and, subject to additional assumptions, could
result in assertions being issued containing unexpected and/or attacker-
influenced data. The full impact depends on how your login configuration
supplies usernames to the rest of the system, and how your attribute
resolution logic is constructed, but it would be very possible for such
an unexpected username to cause havoc or lead to security vulnerabilities.

A "correctly" configured system is not vulnerable, and this issue is not
a bug or flaw in the Shibboleth software. But the primary setting
controlling this behavior in Kerberos, the dns_lookup_kdc flag, defaults
to "true" in Java versions 7 and above (it defaulted to "false" prior).

There are a number of mitigations for this behavior, discussed further

Affected Versions

Above all else, be aware of your Kerberos configuration and how it's
meant to behave. In most cases, you should ensure that the [libdefaults]
section of krb5.conf contains the setting "dns_lookup_kdc = false"
unless you intend for DNS lookup to be used.

In all cases, but certainly if this feature is enabled, it is strongly
advisable to configure the IdP software to verify the KDC by supplying
a service principal and keytab. Such a check guarantees that a realm
other than one known to the IdP cannot be used, regardless of whether
it can be located or not.

Another mitigation is the use of a transformation rule to prevent the
IdP from processing usernames that contain a realm. For example,
something like the following in password-authn-config.xml:

<util:list id="shibboleth.authn.Password.Transforms">
  <bean parent="shibboleth.Pair" p:first="^([^@]+)(@.*)?$" p:second="$1" />

Note well: Oracle's Kerberos JAAS module does NOT support KDC
verification by itself when used in server-side environments. Combined
with their decision to enable DNS by default, it is an unsafe approach
out of the box. Thus, if you make use of the IdP's JAAS support and not
the direct Kerberos support, you MUST be sure to rely on one of the
suggestions in this advisory.


URL for this Security Advisory

Ian Bobbitt, Indiana University's GlobalNOC


Version: GnuPG v2

To unsubscribe from this list send an email to [hidden email]