Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mattermost.com

Post reply on HN
Print view View original

91–100 of 115 posts

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

#91

Post by nine_k »

ByteJockey wrote: post #88
nine_k wrote: post #86

Earlier quoted context omitted.

I wonder how hard would it be to adopt some SAML 2.0 (or maybe just 1.x) with this, and maybe a few other problematic bits updated, but otherwise unchanged? Do you think the rest is worth keeping? E.g. we did not stop using TLS when TLS 1.0 proved to have problems; we updated the cryptography and kept using the logic.

But the problem here isn't he encryption. Well, for all I know, the encryption could be completely broken, I'm not a crypto-expert. But the problem described in the post wasn't the encryption. It was the logic. Specifically the order that things are done in. Parsing something before verifying it can be dangerous.

Indeed! Let's scratch the XMLDSIG entirely and replace it with a sane scheme.

Does SAML have enough salvageable parts to try fixing that, instead of going with something completely different? SAML is so pervasive that migrating off it can't be cheap or easy.

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

#92

Post by Ygg2 »

oever wrote: post #69
lyxsus wrote: post #64

Earlier quoted context omitted.

It doesn't affect data model encoded in document even a tiny bit. Namespace prefixes are irrelevant. If changing these prefixes breaks the program, the program is incorrect.

DTD does not know about namespaces and checks against "prefix:local-name". E.g. the xhtml dtd will not accept this: If you want to change prefixes, use XML Schema or Relax NG.

DTD is the devil spawn. Devil here being massive security vulnerabilities.

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

#93

Post by Mikhail_Edoshin »

russell_h wrote: post #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, t…

It looks intimidating, but it seems to me that most of what happens are standard XML operations. E.g. 1: read XML, 2: use XPath, 3: read element names, structure, and attributes, 4, some parts of: apply XPath or XSLT, if specified, 5: serialize XML (which implies whitespace treatment). Given that the authors of the standard considered the standard XML operations to be readily available, the cryptographic additions do not seem to be that complex.

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

#94

Post by marcan_42 »

tedunangst wrote: post #7

I've never liked (nor understood the popularity) of signature schemes that require parsing before verification. This has also led to problems with X.509. And DKIM. And plists. And package managers. And more. It's much simpler to sign the entire message, unparsed, and it's immune to these issues. We went through a decade of debate before deciding that "encrypt then mac" is the only right way to do things. That knowled…

Yup, as I was reading this I was wondering how this could possibly lead to a critical vuln since nothing would ever depend o... and then I read about how SAML works.

Kill it with fire. This stuff's broken. We know better than to do things this way no. Just no. You sign binary blobs. Signature check fails, your binary blob is garbage and never gets parsed. End of story.

(Mental note: never deploy SAML anywhere)

Aside: I've seen a credit card processor implement nonsense like this, where I had to parse XML with regular expressions to extract the to-be-signed segment, because it was never going to round trip through a typical XML parser. But then again, this was only about the 25th batshit insane and likely insecure thing they were doing, just like every other banking related company, so shrug.

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

#95

Post by ptman »

tptacek wrote: post #83
jupenur wrote: post #77

Earlier quoted context omitted.

Blog author here; Russell's implementation is backed by github.com/beevik/etree, but like you said, it's just an interface. The tokenizer is still encoding/xml. Adding better support for namespaces and providing APIs compatible with dsig doesn't remove the underlying vulnerabilities.

Ugh. That's disappointing. I loathe SAML, but also think the right thing to do here is to make sure nobody uses encoding/xml as part of their SAML stack.

Pardon my ignorance, but what should be used instead of encoding/xml?

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

#96

Post by hakre »

ptman wrote: post #95
tptacek wrote: post #83

Earlier quoted context omitted.

Ugh. That's disappointing. I loathe SAML, but also think the right thing to do here is to make sure nobody uses encoding/xml as part of their SAML stack.

Pardon my ignorance, but what should be used instead of encoding/xml?

I think libxml does not have that problem, IIRC golang supports c-bindings.

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

#97

Post by hakre »

tedunangst wrote: post #7

I've never liked (nor understood the popularity) of signature schemes that require parsing before verification. This has also led to problems with X.509. And DKIM. And plists. And package managers. And more. It's much simpler to sign the entire message, unparsed, and it's immune to these issues. We went through a decade of debate before deciding that "encrypt then mac" is the only right way to do things. That knowled…

as long as binary safe transport is given, possible. unless that ... . you can't skip the memory protocol.

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

#98

Post by GoblinSlayer »

jupenur wrote: post #77
tptacek wrote: post #75

Earlier quoted context omitted.

I share your opinion of SAML, but I have to ask, as someone who has also implemented it in Golang: what gave you any confidence in an implementation backed by encoding/xml? It was to me immediately pretty obvious that DSIG and encoding/xml aren't a fit, if only because of encoding/xml's poor namespace support. There are other DSIG Golang libraries that use an etree-style interface for what I presume is the same reaso…

Blog author here; Russell's implementation is backed by github.com/beevik/etree, but like you said, it's just an interface. The tokenizer is still encoding/xml. Adding better support for namespaces and providing APIs compatible with dsig doesn't remove the underlying vulnerabilities.

Huh, namespaces are a semantic convention on top of xml syntax, tokenizer can't really implement it.

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

#99

Post by GoblinSlayer »

zwass wrote: post #57
russell_h wrote: post #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, t…

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

CAS looks like the simplest protocol to me https://en.wikipedia.org/wiki/Central_Authentication_Service

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

#100

Post by Lorkki »

russell_h wrote: post #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, t…

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

Out of curiosity, what are those reasons?

Post reply on HN