-----BEGIN PGP SIGNED MESSAGE-----
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
steps.

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., name@REALM.ORG)
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
below.


Affected Versions
=================
All


Recommendations
===============
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" />
</util:list>

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.


References
==========

URL for this Security Advisory
http://shibboleth.net/community/advisories/secadv_20170518.txt


Credits
=======
Ian Bobbitt, Indiana University's GlobalNOC


[1] https://wiki.shibboleth.net/confluence/x/f4EEAQ
[2] https://wiki.shibboleth.net/confluence/x/d4EEAQ

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZHbj+AAoJEDeLhFQCJ3li9swP/1otAq9nkKcnGQpUxE4+cODd
UOb4e7oTf5q2h/lP7EjWryxSb5bb7HRFyklDkEi2VgzEpjTiVn5g5Zv2NDL6Ua9O
sMQBVb5Png4hVCQ67oSzLWVxwTMu317U5DqK/YR8TjUjPGOo772/4Pjp/4u8Zb0k
XIq3L8yKxX7ze1M+BB2dTvNW6KIYVHQ++BV9KKyvK5Q5dPP9zHmS0dCTF9fJ7CAk
bGqIYSEPYZdPKAjZzX4b/bT3kzUO2mEwXMTavoJICZU9OukYiq/+dpA9+8/lSKoF
ki7SsiCDrwRyurhJLdIxjNtMxWiplx+6HU0cc7K/GY8d5S+DBt77GV8JTkw3SLUS
5QS2lKCMAWDRBTpcQzDYB5RzejJAa0JMHsSbdDll4iuQLNdFyVVtSNqD6LWk6ttB
jDx+Ysinte2CZLLAQHjnvsenONCpz+/16NZ/61sfNOYo4vkL0oCBO67Ymyj/GvDh
zxKdqNe3PccPVcPRILBT6at4U2ky1LKLILVCDZpdJoPDiPXMr30rzTHBjQVJW7w0
vO2D3RhOG7mtN4GLs2uRQsMod898U0JMZ0sTicDdGKgUK885ufu4n1q/hts/Nurq
51flKgN/r/wJwj+STHk5L+e3K56rEn0x0Ac7WffjL0ygZWTO9rOYf8oLT4UrBPtW
PO4p0uw+UaKVHT5PNwrI
=CltR
-----END PGP SIGNATURE-----