Commented Link: Coordinated disclosure of XML round-trip vulnerabilities in Go’s standard library2020-12-14 #links #go #golang #google #xml #vulnerability
Mattermost, along with Google, announced a vulnerability in the Go XML stdlib. There is a bunch of things to unwrap in this announcement.
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 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.
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.