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

71–80 of 115 posts

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

#71

Post by Everlag »

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…

Aye, this is the 'Cryptograph Doom Principle'[0].

To very lossily summarize: always authenticate before looking at the message.

Its a handy rule of thumb when you're making choices like how to validate a message.

https://moxie.org/2011/12/13/the-cryptographic-doom-principl....

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

#72

Post by ARolek »

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…

I just wrapped up a Go based SAML integration and I was initially using your package. I encounter a bunch of issues with namespaces, and eventually ended up using xmlsec1 directly against a formed up XML template. I agree with you, SAML should go away. This was my first experience with it, and the nuanced complexities were so exhausting. I’m glad the integration is done...

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

#73

Post by cesarb »

vbezhenar wrote: post #67
layer8 wrote: post #53

Earlier quoted context omitted.

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

Yep, in Kazakhstan almost every government web service uses XML signatures for interoperating. Of course nobody sees it outside of those systems, but it's everywhere inside. I have no idea about other countries, but I would not be surprised to find out that there are many other similar countries or organizations where that stuff works inside. You won't know about it until you touch it.

Here in Brazil too, for instance the NF-e (electronic "nota fiscal", the English term seems to be "receipt", the documentation is at http://www.nfe.fazenda.gov.br) and the recently released digital payment network (PIX, see https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn... for the current release of the relevant manual) both use XMLDSig.

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

#74

Post by lyxsus »

layoutIfNeeded wrote: post #68
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.

Again, this is false. “The C14N-20000119 Canonical XML draft described a method for rewriting namespace prefixes such that two documents having logically equivalent namespace declarations would also have identical namespace prefixes. The goal was to eliminate dependence on the particular namespace prefixes in a document when testing for logical equivalence. However, there now exist a number of contexts in which names…

> However, there now exist a number of contexts in which namespace prefixes can impart information value in an XML document.

Well, yeah. They've given up to a mass amount of half-ass implementations? So what? I think it's our moral duty to ignore it :)

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

#75

Post by tptacek »

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…

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

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

#76

Post by userbinator »

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…

This has also led to problems with X.509.

Could you explain more about this? I thought the whole point of ASN.1 DER was to have only one canonical representation for a given structured value, and that the signing was done as-is on the sequence of bytes directly. It definitely doesn't have the same problems as XML and other text-based formats.

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

#77

Post by jupenur »

tptacek wrote: post #75
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…

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.

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

#78

Post by userbinator »

jarym wrote: post #3

Glad this got found. I remember when XML was being widely adopted that there'd be frequent vulnerabilities found in Java-based parsers. A large part of this stems from how complicated XML can get - if it were only elements and attributes it might have been fine. Namespaces made it a bit more complicated. Processing Instructions made it hideous.

XML and many other things related to it (including Java, SOAP, CORBA, etc.) are an example of what could be called "Enterprise mindset" taken to an extreme. Insanely high levels of abstraction and indirection, absurd amounts of needless flexibility and generality, and essentially zero thought given to efficiency or simplicity. It's as if the people responsible for these spent all their time thinking "what's the most complicated way to do something?"

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

#79

Post by userbinator »

jiggawatts wrote: post #43
ben509 wrote: 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…

The issue must be something hideously subtle, like the white space or UTF-8 encoding being subtly different that is upsetting the Microsoft SAML implementations, but not any others.

That is almost certainly the case, as another comment here indirectly references: https://news.ycombinator.com/item?id=25422734

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

#80

Post by hnick »

whatshisface wrote: post #54
hnarn wrote: 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.

I think that would be more analogous to receiving a message, parsing it, then realising the payload is another signed message, and then validating that.

Depending on the situation, signing the container might not even be necessary, much like a zip file without a password that only contains encrypted contents anyway.

Post reply on HN