[website] branch master updated: Add advisory.

[Scott Cantor]

This is an automated email from the git hooks/post-receive script.

scantor pushed a commit to branch master
in repository website.

The following commit(s) were added to refs/heads/master by this push:
       new  839e240   Add advisory.
839e240 is described below

commit 839e2400ead687cecfdb54c6d094f349dcc45bd9
Author: Scott Cantor <cantor.2 at osu.edu>
AuthorDate: Thu May 18 11:09:53 2017 -0400

    Add advisory.
---
 community/advisories/secadv_20170518.txt | 111 +++++++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)

diff --git a/community/advisories/secadv_20170518.txt b/community/advisories/secadv_20170518.txt
new file mode 100644
index 0000000..5b17ffa
--- /dev/null
+++ b/community/advisories/secadv_20170518.txt
@@ -0,0 +1,111 @@
+-----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 at 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-----

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.