Live data from Hacker News

Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

mattermost.com

51–60 of 115 posts

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#51
post #29
post #11

Earlier quoted context omitted.

What makes it worse is that XMLDSIG is exponentially more complicated. Most of the ecosystem literally shells out to libxmlsec1 and assumes it does the right thing. DSIG is a batshit standard that attempts to support arbitrary combinations of signed and unsigned parts in a single document, tied together with a DOM-like scheme, passed through a canonicalizing transformation that has itself broken SAML before. It's a f…

Not to mention that libxmlsec1 has some insane insecure defaults that are effectively undocumented. (I'd go into more details, but i literally just sent a security report yesterday to a saml library for using it wrong, so i guess i shouldn't post publicly about it until they fix)

You probably shouldn't have posted this either.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#52
post #5

Earlier quoted context omitted.

It's really nuts trying to implement something like SAML in XML. The standard is a security minefield.

I've been cavorting around that minefield recently. I still have some of my legs and a tiny bit of my sanity. The most recent "fun" I had was that on a Citrix NetScaler, if you enable a certain n-Factor workflow, it sends a SAML request to the IdP that Microsoft products only reject as "invalid XML". From what I can gather the XML being sent is perfectly valid. The issue must be something hideously subtle, like the w…

oh wow that's disgusting, why would someone design something like this.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#53
post #42

Earlier quoted context omitted.

I don't doubt it was a mistake, but I'm curious what the alternative is here? I'm looking to add SAML to my to project in the medium-term.

SAML is the only mainstream user of XMLDSIG and 99%+ of the installed base of XMLDSIG. SAML libraries should include purpose-built, locked-down, SAML-only XMLDSIGs, and those XMLDSIGs should include purpose-built, stripped-down XMLs. The XML isn't even the hard problem here! XMLDSIG and XML Canonicalization are much more complicated than the baseline XML parser.

> SAML is the only mainstream user of XMLDSIG

That’s not quite accurate. XMLDSIG is widely used in SOAP, and also in the European XAdES signature standard (which is an extension of XMLDSIG).

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#54
post #47

Earlier quoted context omitted.

I believe the problem being addressed is where the payload may be transcoded in flight or otherwise not delivered in exactly the same form. Put another way: the signature validates the payload, however it may end up being represented to the validator on delivery. It isn't simply a transport integrity measure.

I might be missing the point here, but isn't the whole idea of signing a message that it should not be possible to "transcode the message in flight"? If you even allow the message to be "not delivered in exactly the same form" in the first place, you're introducing an attack vector completely without reason, because what you instead could do is let the payload be strongly signed and unchanged, and then have differing…

You sign your letter and seal it in an envelope. I put your envelope into a cardboard box and give it to your friend. Your friend refuses to open your letter because you did not sign my box.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#55
post #47

Earlier quoted context omitted.

I might be missing the point here, but isn't the whole idea of signing a message that it should not be possible to "transcode the message in flight"? If you even allow the message to be "not delivered in exactly the same form" in the first place, you're introducing an attack vector completely without reason, because what you instead could do is let the payload be strongly signed and unchanged, and then have differing…

You sign your letter and seal it in an envelope. I put your envelope into a cardboard box and give it to your friend. Your friend refuses to open your letter because you did not sign my box.

No, this is more like your friend refusing to trust the contents of the letter after the mailman cut the letter into small pieces and glued them back together.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#56
I'm the maintainer of one of the affected SAML libraries.

People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it:

When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, then signs that document using a thing known as an XML Digital Signature, or XMLDSIG.

When you think of "signing" a document, normally you would serialize that document out to bytes, apply your signature scheme over the bytes, then send along both the bytes and the signature. But for reasons which are irrelevant to modern implementations, XMLDSIG prefers to stuff the signature metadata back inside the XML document that was just signed. Obviously this invalidates the signature, so you also inject some metadata instructing receivers on how to put the document back how it was. There are several algorithms available for this. Then you ship around that XML document. Basically means that when the Identity Provider receives one of these documents it needs to:

  1. Parse the XML document (which cannot yet be trusted)
  2. Find the signature inside the document
  3. Find the metadata about what algorithm(s) to use to restore the document
  4. Run the document through whatever transforms are described in that metadata (keep in mind that up to this point the document might well have been supplied by an attacker)
  5. Serialize the transformed document back out to bytes, being careful not to touch any whitespace, etc
  6. Verify the signature over the re-serialized document
If all of this succeeds and was implemented perfectly, you can trust the output of step 5. Ideally you should re-parse it. A common failure mode is trusting the original input instead, so be careful about that.

Obviously this is a crazy approach to one of the most security-critical parts of an application on the internet, and it breaks all the time.

Unfortunately people persist in using this fundamentally broken protocol, so huge thank you to the team at Mattermost for their research in this area.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#57

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

As a service provider, are there viable alternatives to support SSO in an application?

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#58
post #9

XML I'm amazed people can get it as right as they do half the time? I do think Go will get fixed eventually. It's just too weird if they couldn't fix the core issue? But I've never used XML if I can help it, so I'm absolutely no expert on what would make it impossible to fix something like this.

They can fix the core issue... they can not do so while maintaining the 1.0 backwards compatibility promise. The data structures in encoding/xml in Go 1.0 are fundamentally incorrect for this use case.

Is you sense they will maintain the promise? That is commitment (and I wouldn't be surprised if true). Could they add a flag / toggle to the existing API you could toggle to change behavior or do they need an entire new API?

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#59
post #57

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

As a service provider, are there viable alternatives to support SSO in an application?

OpenID Connect seems to be pretty well established: https://openid.net/certification/

It defines an authentication protocol on top of OAuth2, and is a different beast from the older OpenID standards.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#60
post #57

I'm the maintainer of one of the affected SAML libraries. People need to stop using SAML. This needs to be a priority. A little background, for those who haven't had the displeasure of working with it: When a user wants to log into an application (the "Service Provider"), and is required to SSO against an "Identity Provider", the Identity Provider basically generates an XML document with information about the user, t…

As a service provider, are there viable alternatives to support SSO in an application?

Depending on who your customers are, you might get away with only supporting OIDC. But not supporting SAML is going to be a problem as you move into the big enterprises.

Many big companies run on SAML, and expect to auth with vendors over SAML. That's why russell_h's comment is probably futile; it's the enterprises with the big SaaS budgets that keep SAML relevant, and they don't care if HN doesn't like it.

Maybe in about a decade SAML will be less important to enterprises? SAML 2.0 is only about 15 years old.

Post reply on HN