Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2011.1071
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:
http://shibboleth.internet2.edu/secadv/secadv_20111024.txt
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
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
future.
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"
locations).
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.
Credits
=======
Tibor Jager, Juraj Somorovsky
Horst G�rtz Institute for IT Security,
Ruhr-University Bochum
URL for this Security Advisory:
http://shibboleth.internet2.edu/secadv/secadv_20111024.txt
[1] http://www.nds.rub.de/research/publications/breaking-xml-encryption/
[2] http://www.w3.org/TR/xmlenc-core/
[3]
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPSAML2SSOProfileConf
ig
[4] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall
[5]
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPStatelessClustering
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iQIcBAEBCgAGBQJOpYlxAAoJEDeLhFQCJ3liCKwQAKXKJham8GE5a91vRvxHu2CL
psy4O2bEr6RTj96c0Dh/8DvcxcS1WtdybhzOfdc6jVgrXawbsyufk8OO+xRU/QOB
81IMwW8X5IyqrqtuG2lUH7MVDD6HX2NW7pbV0B633leSJHo/BUxb2SO7Pg2UYdno
TH5FACetvtcGoDnHqDG4/ZC776G2XMcZC8UeKJS+F3CKg45CPnmSm65F3ZkS8a0b
uck8o4SiB2rj6O7oP2D3JP7KatzCQeq6Gu9v7suBgoC/Aq5rhVflJ2ETWIScUWv7
Ko2+CzHng3hv2MBug1nPN3b2y1K5N1BOW6q5Gmu3YMDpuDHJ6SlfMozlJPQeQqLG
OJnfCAFttmeCuOtXIiOsqym5tXxLEC7ipShlcVxrmk7Kte9twU1W/BIG2WFXxZJp
dm+wGgFBDG24ECVfmcaKNau4F5E8MsmbS+N2/Z4ufOGL+P3DjXk6UhBJ0TBCdm6I
vWd7wHnG5OeR2A5hPZGDREwyk1DkWKQ61gjBO5xeKUH1LoYc0/xFEN5uhLebK7Fe
zZsQCyomlJperLeucM4IK8MlLfWvL5rfXUowbu8LMfQBSKQapDou0o3DIrqVFNFs
TPsAG6YVWlJ4Xvg0ctKM+MJtW+CLGRSw6qL35OuJA6rT0JJ5hOJ/ChnxF1MFtEOm
sXd6VXzxPOgkVlsV7AEI
=ISWt
- -----END PGP SIGNATURE-----
- --------------------------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:
http://www.auscert.org.au/render.html?cid=1980
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
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.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBTqZEOO4yVqjM2NGpAQIqkw//b0V+t0L8t9sCevvV2TdvhfVvyLvaiIsk
WGQIDmP83FsoUwZ5am7YV63WmGsFuH3OzezdFHZSBhRABdMme6jCozL0XAVFpeYz
6ubyRX40jzxM5dZiKGK3nP7bVgJm5jgFxR78JjlSGEE9vE0bir4v4iT/ksCppcrG
dOogsX8LSQQCQ9dDTYIoDt6aMW4/GvC9IipkUrT8VsGVfaQJzNA0xpL8i8pLjUfB
phrLLG7BfZaNXqbnG/NoS5bqVHyNBZ02LVANDbQ3GtwkJZr+iEAg8BdGA1VFsR7I
6eQCqIRAbdFSPstKQMPGtg6K+tSmL4xnFcsaemxlO21SQ6UIf+TeoAjTsVzhMhkm
yiZRzB6LvTu5mDpRC/p1JmHKuP10UTRtg3e+Citohvn5ie7q0wpg2VgAkXn5EAA0
FRWnIk6HILDZUpF8aweW/yF4++UVOGWFhOxcvOkF0+wv3PvtjUyXWEWOKKzrIExt
Qm2+eWxCGHRuVMUFz5x3B2M7B0HarRBh4rp0TLQaLhZdO80tn1QpqkWn2wizTwl4
9FfaaYRYeVlozl1a0aPGWinv16u8z90OTnBHq+SsT/gIyXvl/cPIjWUz5QUaoH0g
R00jdkql7aHfJ9MftYKYYJYRS7S4aaMrh0SUVrrtywgSHBs2M/tuaGOvaivf2N6i
fwOhraH3fSE=
=qtzS
-----END PGP SIGNATURE-----