XM-Hell strikes single-sign-on systems: Bugs allow miscreants to masquerade as others

Various single-sign-on systems can be hoodwinked to allow miscreants to log in as strangers without their password, all thanks to bungled programming. Specifically, the vulnerable authentication suites mishandle information submitted in the XML-like Security Assertion Markup Language (SAML). These weaknesses can be potentially …

[Christoph]

This has always been the problem. Single sign on = single point of failure.

[Pascal]

single point of failure maybe,

But the alternative is requiring people to have 15 login/passwords to 15 systems.

This results in the same password being used everywhere, or passwords written down on post it notes, and so on.

And obviously, 15 actual point of failures within 15 different login processes.

In theory one secure and thoroughly vetted sign-in system should mean less risks.

[fobobob]

Re: single point of failure maybe,

I find privately managed password managers (e.g. KeePass) to be effective at dealing with this, though it's not without its faults too. Developing a password scheme that incorporates a mnemonic based on the particular login, but could not be readily guess if another one was seen might also be something to consider.

[Brian Miller]

Sign ALL the data

Signatures are supposed to cover all of the data, not just some of it. I found an ARM processor whose weakness was using an encrypted image. The signing was done over the plain text, but not the encrypted portion. So you could swap out the encrypted portion and still have a valid firmware image, according to the signature.

[IndianaJ]

Re: Sign ALL the data

I was also under the mistaken impression that signatures operated across all the data it was signing.

[Michael Wojcik]

Re: Sign ALL the data

I was also under the mistaken impression that signatures operated across all the data it was signing.

That's not a mistaken impression (modulo the disagreement in number you have there). That's exactly what a signature does: signs the data that it signs.

The issue here is that SAML implementations did not use consistent canonicalization algorithms, so they could potentially sign and verify different things.

Many signature protocols have an initial canonicalization step before hashing and computing the signature. That permits greater flexibility in transmitting and representing the signed data. The downside is that the canonicalization has to be done consistently, by all parties, for signing and for verification.

XML is (too) complicated, which means XML Signature is (too) complicated, particularly in canonicalization. And so errors like this are easy to introduce.

[Tom 38]

Only vulnerable if you use HTTP-POST binding

Only vulnerable if you use HTTP-POST binding to deliver the SamlResponse to the service provider, if you are using other bindings like HTTP-Artifact then there is no chance for the response to be modified.

Admittedly, that is the most common - I don't know why, it makes the client requirements so much stronger.

[Brian Miller]

Just read the specs...

And of course I'm not surprised SAML has problems. 93 pages of dense specs, written by 62 people.

There is much goodness in simplicity. SAML is not a simple thing.

[fobobob]

Re: Just read the specs...

I tend to see references to it in bloated, cumbersome helpdesk systems and other customer portal type things... never been impressed.

[Anonymous Coward]

Re: Just read the specs...

We implemented a SAML based portal at work about 10 years ago. If you think you found the SAML spec and it was 93 pages, you've probably only found a part of it. There are at least 5 spec documents (Core, Bindings, Metadata, Profiles, Conformance), each one around 100 pages, each one written by committee.

The choice to use SAML was not ours - we spent the first 2 months each with printouts of these specs attempting to work out which of the eleventy billion options to use. I'm sure the authors (IBM, Oracle, Sun, Intel, HP, Booz Allen Hamilton (fascinatingly!)) of the "spec" actually designed it so that it was so complex that in order to use it, you have to use their tool to do so.

[Alistair]

Re: Just read the specs...

Asymmetric validation.

what the hell. I'm not even a particularly mathy techie, and I'd be setting something on fire for that gap.

" Booz Allen Hamilton (fascinatingly!)" < > Please read that as "Ex spooks who are raping their former employers"

"it was so complex that in order to use it, you have to use their tool to do so." Effective sales pitches are effective sales pitches, even in the 'Open Source Software' world.

[Nimby]

Security Done Wrong

"carefully alter the valid SAML response so that it has a stranger's account ID instead of your own, all while keeping the signature valid"

Eh? I know this is a simplified summary of the bug, but if the concept really is that simple, and multiple implementations contain the same stupid bug, then SAML folk really has no idea what security means. Because that's just ludicrous. You shouldn't be able to change one single bit without invalidating the signature. I sure do hope that the reality is a lot more complex than this sounds.

[Michael Wojcik]

"XML-like"

SAML is not "XML-like". It is XML. Protocol messages are represented in XML. Of course there is a schema - it's not arbitrary XML - but neither is it "XML-like".