Hash: SHA1

             AUSCERT External Security Bulletin Redistribution

              Shibboleth Security Advisory [24 October 2011]
                              25 October 2011


        AusCERT Security Bulletin Summary

Product:           Shibboleth
Publisher:         Shibboleth
Operating System:  Windows
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Access Confidential Data -- Remote/Unauthenticated
Resolution:        Mitigation

Original Bulletin: 

- --------------------------BEGIN INCLUDED TEXT--------------------

Hash: SHA512

Shibboleth Security Advisory [24 October 2011]

A flaw exists in the algorithms specified by the XML Encryption
standard that can lead to exposure of personal information under
certain circumstances.

There is no simple fix for this issue, so deployers are encouraged
to consider their use of certain software features and possibly
make changes to their configurations if circumstances warrant,
as described below.

We welcome discussion on the users@shibboleth.net mailing list.

This advisory is not particular to either the Shibboleth Identity
or Service Provider software, but is more generically addressed
at deployments "in total". Improvements or patches in both software
components, or possibly the OpenSAML libraries, may be made in the

Note that the integrity of the information and the overall security
of the software is not affected by this problem. The threat is to the
confidentiality of the information encrypted by the software.

This issue is rated "important".

Use of XML Encryption Vulnerable to Chosen Ciphertext Attacks
The Shibboleth software supports the use of XML Encryption to
encrypt SAML assertions in transit, particularly as they pass
through clients from an Identity Provider to a Service Provider.
By default, this feature is enabled in conjunction with SAML 2.0
Browser SSO so that user information can be encrypted end-to-end
without relying on back-channel communication from SP to IdP.

A just-published paper[1] has disclosed a set of attacks against
the data encryption algorithms specified for use by the XML
Encryption 1.0 standard[2], specifically due to the use of
"CBC" mode. All of the data encryption algorithms specified,
and widely implemented, for use with XML Encryption are affected.

An attacker that can obtain a copy of an encrypted assertion can
craft requests to a Service Provider that gradually disclose the
decrypted data because of differences in processing time for
valid and invalid messages. The exact degree to which the SP
software is vulnerable on the basis of timing measurements is
unclear, but we are erring on the side of caution in assuming that
such attacks are possible for a sophisticated adversary.

We do not believe that an attacker would receive information from
the SP in response to messages that would disclose enough information
to aid in the attack, so the threat is lower as a result; timing
attacks require more sophistication.

Identity Provider Issues and Suggestions
The Identity Provider software does not, at this time, support the
use of XML Encryption on data it receives. As a result, the
implications of this problem are limited to the encryption of data
that it sends, typically as a result of SAML 2.0 authentication
profiles. The use of SAML 1.1 is not affected, because it did
not support XML Encryption.

Deployers should consider what sort of user information they are
passing through the client, and make a determination as to whether
the risk of disclosure is acceptable. An important factor includes
whether web sites that do not rely on TLS are supported, since the
data in such cases is exposed not only to the client, but the network.

Therefore, if deployers are sending sensitive information and either the
browser is not trusted or the SP is not using TLS, we recommend that you
do not "push" attributes[3] within the SSO assertion.  While the
query endpoint is enabled by default, some deployers may not have
provided for a back channel endpoint, since an additional port
and more advanced web server setup[4] are required, so this may not
be a simple change.

Note also that not all SP implementations support queries; addressing
the problem in those cases may be impossible, or may require the use
of the HTTP-Artifact binding; note that artifact usage requires not
only the back channel, but imposes requirements that are incompatible
with stateless clustering strategies[5].

Finally, as a more forward-looking change, deployers may consider
enabling the signing of SAML responses in addition to or instead of
assertion signing. This was a default on older Shibboleth versions,
but was recently changed to align to industry best practice. New
advice as to appropriate defaults is expected to emerge as the flaw
is further analyzed.

Future Service Provider versions may allow for response signing
as a mandatory check, because one mitigation of the XML Encryption
flaw is to digitally sign all encrypted data to prevent an
attacker from manipulating it. Because of compatibility considerations,
it is unclear at this time whether making such a policy a default
will be practical or not.

Service Provider Issues and Suggestions
The Service Provider in general acts as a recipient of encrypted
data, although it does support encryption of user identifiers
in conjunction with SAML 2.0 Single Logout and other even more
obscure features. In those outbound cases, some of the same
considerations noted for the IdP apply, but overall the threat
is rather minimal, particularly given the common use of
per-session identifiers for users in Shibboleth, and because
in most cases the messages are also digitally signed.

However, the SP is the primary source of the vulnerability overall
because it acts as the "oracle" for an attacker attempting to break
the encryption of data sent to it by the IdP. As a result, it is also
the point at which future changes may be made to mitigate the attack.

In the meantime, it is obviously helpful to deploy SPs with TLS
enabled, at least for the SAML endpoints (i.e., the "handler"

Shibboleth SPs as a rule will also automatically query for attributes
if an IdP does not supply any. So, no explicit changes need be made in
most cases to support IdPs that want to switch from "pushing" attributes
to the "pull" model used by default with SAML 1.1. Of course, some
deployments may have firewall issues that prevent or complicate this.

If a future SP release includes mitigations for this problem, this
advisory will be updated or reissued to reflect the changes made and
describe any associated configuration steps that should be taken.

While there are proposed encryption algorithms likely to be
standardized by XML Encryption 1.1 to address this overall problem,
at this time we do not expect to see quick availability because the
native library support that the SP relies on is not available as of
yet. This may of course change in response to this flaw, but our
expectations for this are low at the moment.

Tibor Jager, Juraj Somorovsky
Horst G�rtz Institute for IT Security,
Ruhr-University Bochum

URL for this Security Advisory:

[1] http://www.nds.rub.de/research/publications/breaking-xml-encryption/
[2] http://www.w3.org/TR/xmlenc-core/
[4] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall
Version: GnuPG v1.4.11 (Darwin)


- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:


Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
Comment: http://www.auscert.org.au/render.html?it=1967