Shibboleth Identity Provider and OpenSAML-J Security Advisory - [25 February 2015]

[Brent Putman]

Apologies, resending with GPG signature.

--Brent

******************************


-----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


Credits
=======
Brent Putman, Shibboleth Project and Georgetown University


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEAREKAAYFAlTuSOsACgkQTTdwW2HLCz+qwQCcDE73B8uJdM6tke0KEUlPisFA
ho0AnRtaj2Qqq7js9kutSzYEbQXbzoi+
=/WGZ
-----END PGP SIGNATURE-----