-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Shibboleth Security Advisory [ 25 February 2015 ] Identity Provider and OpenSAML-J PKIX Trust Engines Exhibit Critical Flaw In Trusted Names Evaluation ======================================================================= A critical flaw has been discovered in the PKIX trust components of the Shibboleth Identity Provider and OpenSAML Java that allows a candidate X509 credential to be trusted in the special case where no trusted names are available for the candidate entityID. A software upgrade and/or changes to consumed SAML metadata is required to mitigate the issue. The Shibboleth Identity Provider and OpenSAML Java support a PKIX model for establishing trust of an entityID's X509 certificate (Credential), by establishing that the entity's certificate is signed by a trusted authority. A crucial part of this trust model is ensuring that one or more of the certificate's names (e.g. subject common name (CN), subject alternative name extension) is a "trusted name" known to be valid for the entity based on a trusted source of information, such as SAML Metadata. A critical flaw has been discovered in the PKIX trust components that allows an X509 credential to be trusted in the special case where no trusted names are available for the given entityID. With the Shibboleth SAML Metadata-based PKIX trust model and the use of shibmd:KeyAuthority elements representing trust anchors, this condition exists when an entity has no KeyName elements in its RoleDescriptor's KeyDescriptor. This is a potentially common condition, since many entities publish only a certificate in their metadata; in these cases their trust is typically established via the alternative "explicit key" model. The practical result of this flaw is that if the IdP has a metadata-based PKIX trust engine enabled, anyone in possession of a certificate issued by one of the shibmd:KeyAuthority trust anchors may impersonate any entity described in that metadata within the scope of that shibmd:KeyAuthority which does not contain at least one KeyName in its RoleDescriptor's KeyDescriptor. The Shibboleth IdP ships with metadata-based PKIX trust engines enabled by default. In relying-party.xml, the security:TrustEngine elements with id values of 'shibboleth.SignatureTrustEngine' and 'shibboleth.CredentialTrustEngine' by default are defined as a chaining engine consisting of a MetadataExplicityKey- engine followed by a MetadataPKIX- engine. The MetadataPKIX- engines are vulnerable to this flaw. Affected Versions ================= Versions of OpenSAML Java < 2.6.5 Versions of the Identity Provider < 2.4.4 Recommendations =============== OpenSAML users: Upgrade to OpenSAML Java 2.6.5 or greater, if PKIX trust engines are in use. PKIX trust engine implementations in this version will fail a candidate credential if no trusted names are resolved for the relevant entityID; the existing PKIX resolver implementations now also automatically treat the target entityID as an implicit trusted name. If this is not feasible, ensure that ALL entity data resolved via instances of PKIXValidationInformationResolver have at least 1 trusted name which is resolveable. For resolvers based on SAML metadata, see IdP recommendations below. IdP users: Upgrade to IdP 2.4.4 or greater, if PKIX trust engines are in use. PKIX trust engine implementations in this version will fail a candidate credential if no trusted names are resolved for the relevant entityID; the existing PKIX resolver implementations now also automatically treat the target entityID as an implicit trusted name. If this is not feasible: For any configured StaticPKIX- trust engines, ensure that they are configured with at least 1 TrustedName child element. For all configured MetadataPKIX- trust engines: Only metadata sources which contain Shibboleth KeyAuthority extensions are affected by this flaw. Metadata which does not contain KeyAuthority extensions is not effectively usable with the PKIX trust model in general. If examination of the relevant source metadata shows no KeyAuthority elements present, then that particular MetadataPKIX- engine instance is not susceptible to this issue. If KeyAuthority elements ARE present in the relevant metadata: If the metadata in use with a MetadataPKIX- trust engine is local and/or under the IdP's control, one approach for remediation is to ensure that all RoleDescriptors (in particular SPSSODescriptors) represented and within the scope of a KeyAuthority have at least 1 KeyName within their KeyDescriptor elements containing a key name, EVEN IF that entity's KeyDescriptor already contains a key (e.g. an X509Data/X509Certificate element) used with the "explicit key" trust model. If metadata in use with a MetadataPKIX- trust engine is not under the control of the IdP (e.g. is published by a federation), the federation or publisher would need to take the necessary steps outlined above to ensure that all RoleDescriptors have at least 1 KeyDescriptor/KeyName. In the above case an IdP deployer may of course chose to disable MetadataPKIX- trust engines until such time as the consumed metadata meets these requirements. For both cases, an alternative approach would be to restrict the scope of the KeyAuthority extensions to particular EntityDescriptors and/or EntitiesDescriptor groups. This may be implemented by one of the following methods: 1) Define a distinct MetadataProvider and associated MetadataPKIX- trust engine based on this new metadata source, and move all EntityDescriptors using PKIX and their KeyAuthority extensions to this new source. 2) Create a dedicated EntitiesDescriptor group within the existing metadata and move the KeyAuthority extensions and EntityDescriptors which use the PKIX model to this EntitiesDescriptor group. 3) Copy relevant KeyAuthority extensions down to individual EntityDescriptor elements, and then remove them from the ancestor EntitiesDescriptor. Examples of these approaches are available in the Shibboleth wiki at: https://wiki.shibboleth.net/confluence/display/SHIB2/20150225+Security+Advisory+Examples References ========== CVE-2015-1796 OpenSAML Java: PKIX Trust Engines Exhibit Critical Flaw In Trusted Names Evaluation URL for this Security Advisory http://shibboleth.net/community/advisories/secadv_20150225.txt Credits ======= Brent Putman, Shibboleth Project and Georgetown University -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEAREKAAYFAlUDKzEACgkQTTdwW2HLCz9i6ACaAtnQ8r39B7lRgYAR2VIv26Yg ntIAni5D0lTEutW8mFQspEMcKMH3jxPa =OPmj -----END PGP SIGNATURE-----