Shibboleth Security Advisory [24 October 2011]

Tue Oct 25 18:26:52 BST 2011

I am trying to be sure I understand all the implications of this advisory.  I am hindered by my ignorance of the inner workings of the IdP and SP software (not to mention networking and security).  I'm concerned about this statement:

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

Is it only attributes that are exposed?  Or does the SSO assertion contain other items, for example, session or SSO tokens, that might also be revealed?

Also, I am confused by the idea of whether "the browser is not trusted."  My understanding is the browser is not trusted until the user has authenticated successfully, and then it is (for better or worse).  Or am I confused, I mean, can attributes be pushed to the browser even without successful authentication -- if that's so, then the browser would never be trusted.  Yes, I am definitely confused.  Please straighten me out, thanks.

Jim Green
Michigan State University -- Identity Management

On Oct 24, 2011, at 12:00 PM, Cantor, Scott wrote:

> -----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 at 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-----
> 
> --
> To unsubscribe from this list send an email to announce-unsubscribe at shibboleth.net