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

61–70 of 115 posts

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

#61

Post by jiggawatts »

ikiris wrote: post #52
jiggawatts wrote: post #43

Earlier quoted context omitted.

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.

It's the most egregious example of design-by-committee that I have ever seen.

Everything about SAML is about 10x more complex than it technically needs to be.

On top of that, it has so many optional features that interoperability problems are likely even between 100% standards compliant implementations.

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

#62

Post by blablabla123 »

nimish wrote: post #37

`encoding/xml` has had broken handling of namespaces for a long time. It’s possible to hack it on but the only reasonable choice is to use a libxml2 binding which also gets you canonicalization, another can of worms. Unsurprised it can cause security issues, especially in XML-DSig which is a nightmare to handle correctly.

Yup, I think it becomes very quickly obvious when using `encoding/xml` with XMLs that have multiple namespaces that the handling is incomplete. Hard to believe such an xml could even survive one roundtrip. It's also documented that the implementation is incomplete:

Mapping between XML elements and data structures is inherently flawed ... See package json for a textual representation more suitable to data structures.

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

#63

Post by layoutIfNeeded »

lyxsus wrote: post #24
jerf wrote: post #6

Anyone have examples of XML that can be mutated? My guess is that it wouldn't take much. I expect that a similar problem will be found in many other libraries, if the XML was publicized. XML namespaces made a critical... "mistake" is probably too strong, but "design choice that deviated too far from people's mental model" is about right... that has prevented them from being anywhere near as useful or safe as they cou…

> This breaks people's mental models of how XML works, and correspondingly, breaks people's code that manipulates XML. Because they usually have incorrect mental model. Blaming namespaces for name ambiguity would be the same as blaming the code "x = a + b" because "a" and "b" could be defined differently. Namespace prefixes are absolutely irrelevant, they only exists for your convenience.

>Namespace prefixes are absolutely irrelevant, they only exists for your convenience.

This is false. As soon as you need XML canonicalization you very much need those prefices exactly as they were present in the original document.

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

#64

Post by lyxsus »

layoutIfNeeded wrote: post #63
lyxsus wrote: post #24

Earlier quoted context omitted.

> This breaks people's mental models of how XML works, and correspondingly, breaks people's code that manipulates XML. Because they usually have incorrect mental model. Blaming namespaces for name ambiguity would be the same as blaming the code "x = a + b" because "a" and "b" could be defined differently. Namespace prefixes are absolutely irrelevant, they only exists for your convenience.

>Namespace prefixes are absolutely irrelevant, they only exists for your convenience. This is false. As soon as you need XML canonicalization you very much need those prefices exactly as they were present in the original document.

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.

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

#65

Post by vbezhenar »

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…

I agree that it's a bad idea. I had an issue with two XML libraries with different languages. One did XML signing, other did verifying. They just did not work, properly signed message failed to validate. I tried to debug, but those standards were incomprehensible, there are thousands of LoC dedicated to normalization and whatnot. You need few dozens of LoC to sign or verify bytes and you need incredible complexity to implement that XML security thing.

But the issue is: those standards are out there and they're used and probably some people will use it in new projects and you have to interoperate with them.

So yeah, don't use those standards when you can, but sometimes you have to.

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

#66

Post by syrrim »

hnarn wrote: post #47
dboreham wrote: post #39

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…

Usually, signing the whole damn thing is too computationally expensive, so you sign a hash instead.

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

#67

Post by vbezhenar »

layer8 wrote: post #53
tptacek wrote: post #42

Earlier quoted context omitted.

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

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.

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

#68

Post by layoutIfNeeded »

lyxsus wrote: post #64
layoutIfNeeded wrote: post #63

Earlier quoted context omitted.

>Namespace prefixes are absolutely irrelevant, they only exists for your convenience. This is false. As soon as you need XML canonicalization you very much need those prefices exactly as they were present in the original document.

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 namespace prefixes can impart information value in an XML document. For example, an XPath expression in an attribute value or element content can reference a namespace prefix. Thus, rewriting the namespace prefixes would damage such a document by changing its meaning (and it cannot be logically equivalent if its meaning has changed).”

https://www.w3.org/TR/xml-c14n/#NoNSPrefixRewriting

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

#69

Post by oever »

lyxsus wrote: post #64
layoutIfNeeded wrote: post #63

Earlier quoted context omitted.

>Namespace prefixes are absolutely irrelevant, they only exists for your convenience. This is false. As soon as you need XML canonicalization you very much need those prefices exactly as they were present in the original document.

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.

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

#70

Post by lyxsus »

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.

I would say use XML Schema at least. DTD looks alien to XML anyway.
Post reply on HN