Shibboleth Service Provider Security Advisory [27 February 2018]

[Baron Fujimoto]

On Tue, Feb 27, 2018 at 03:00:30PM +0000, Cantor, Scott wrote:
>I'm taking the unusual step of adding a follow up announcement on this for a couple of reasons. Firstly, it's not solely a Shibboleth bug and there's a blog article from the Duo researcher now that people should know about. [1]
>
>Secondly, the implications here may not be clear, so I want to reinforce this: people have not found all the implementations that are vulnerable to this bug and its siblings. CERT reached out to many, but they can't hit everybody, and they naturally omitted a whole lot of the one-off stacks out there used by cloud vendors which many in this community use Shibboleth routinely to integrate.
>
>As part of my nature study for this process, I investigated, discreetly, a number of SPs that my university has campus-wide integrations with and that did not support XML Encryption. This is the sweet spot for the bug, because truncation attacks generally require overlapping user identifiers, and 150,000 identities provides that kind of thing.
>
>Out of about 6 I checked, 4 were vulnerable and none of them likely know about this yet. I've started my own campus process of reporting the issues and turning the long crank of getting the vendors aware of them. Unfortunately, this is a process that many of us are going to have to spend time on.
>
>Some of them were vulnerable to the previous bug we fixed last month, and I also am not even sure that Duo understands the full range of potential flaws here because I found successful attacks that were similar to, but not the same as, the one they formally reported. This is going to be a process.
>
>Again, focus on the unencrypted integrations. I would also urge all of us to begin to insist on the use of XML Encryption going forward. We will also need to begin the long process of forcing implementations to get compliant with AES-GCM encryption, which will be the default in Shibboleth V4, and which replaces the long-broken AES-CBC encryption used almost universally in SAML today. It's time to fix that.
>
>-- Scott
>
>[1] https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

Apologies for the dumb question, but is there a way to determine, from the IdP end of things, whether any of the SPs we integrate with may be vulnerable because they do not support XML encryption? 

Aloha,
-baron
-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum