==================================================================== CERT-Renater Note d'Information No. 2017/VULN162 _____________________________________________________________________ DATE : 30/05/2017 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Shibboleth Identity Provider. ===================================================================== http://shibboleth.net/community/advisories/secadv_20170518.txt ____________________________________________________________________ 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: 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 ========================================================== + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: cert@support.renater.fr + ==========================================================