blog/content/links/go-xml-vulnerability.md

+++
title = "Commented Link: Coordinated disclosure of XML round-trip vulnerabilities in Go’s standard library"
date = 2020-12-14

[taxonomies]
tags = ["links", "go", "golang", "google", "xml", "vulnerability"]
+++

Mattermost, along with Google, announced a [vulnerability in the Go XML
stdlib](https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/).
There is a bunch of things to unwrap in this announcement.

<!-- more -->

Before anything, I need to point out that I never liked Go. I don't
like the way they deal with the community, I don't like their error
reporting way and I don't like their code style. I take every chance
to bash the language. But this time, I think the brokenness went too
long.

First of all, sure, there is a vulnerability in the XML library. The
vulnerability by itself and not huge -- it basically means, by what I
got, that the library itself doesn't keep the order of elements inside
-- but its the use in some huge elements, like SAML, affects the way
the protocol works. So, basically, something that would look like a
well-formed XML/SAML content would be interpreted in the wrong way
'cause the system is changing the semantics of it by changing the
order.

Second, apparently, since the vulnerability was found, the go security
team have been working on fixing the issue, with no success. The
resolution after all this was "the root causes of the vulnerabilities
cannot be reliably addressed." That means that the stdlib now have a
vulnerability that can't be fixed.

Third, this vulnerability was found in August this year and only now,
four months later, the vulnerability was disclosed and announced that
it can't be fixed. This is extremely infuriating 'cause Google have a
project called "Project Zero", created to find and report
vulnerabilities in several products. The problem is this is the third
not-so-small vulnerability in go code, and none of them were found by
Porject Zero. On the other hand, they are pretty quick in pointing and
disclosing -- with a 30 day allowance -- issues in Windows or iOS, for
example.

Oh, and in case you're wondering what were the other issues, the first
was related to [the cryptographic
libraries](https://twitter.com/peter_szilagyi/status/1332047468004077569)
and basically affected a bunch of Etherium applications. The second,
an issue with the "http" library, which could lead to [a
denial-of-service in
Kubernetes](https://www.bleepingcomputer.com/news/security/severe-flaws-in-kubernetes-expose-all-servers-to-dos-attacks/).

Also... Four months and no solution? That means there is something
seriously broken in go internal architecture that doesn't allow
something like ordering to be applied.

But back to the main issue: Fourth, the company that worked with
Google to find and helped in trying to fix the issues, pointed that
they don't believe the changes proposed by the go team will actually
fix the problem. By their words, it seems Google just want to throw
the issue under a rug and, when it blows up, they will say "it's your
own fault, we told you so".

Google solution is, basically, "we'll put in the documentation and
hope for the best". So, no fix at all. Honestly, the proper solution
would be remove the whole thing and let someone else, hopefully
smarter, write a proper XML library. We say no documentation is better
than wrong documentation, so no XML library is better than a broken,
vulnerable library.

Another solution is to create binds to libxml2, which is a C library
that powers a lot of other languages XML needs. This would mean that
the standard library would require external tools to properly build,
though.

Personally, with all that is going on with the language, using it for
any half-serious (or higher) project is completely stupid.

PS: Just after I posted this, someone send me an announcement from the
go team about a new release fixing a vulnerability in the stdlib "ssh"
library. Again, anything that is at least half-serious shouldn't use
go.