From c16e73c50b4c2a912826ef7e71bb7b3f76a931c8 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 14 Dec 2020 22:12:34 -0300 Subject: [PATCH] Commented Link: vulnerability in go --- content/links/go-xml-vulnerability.md | 78 +++++++++++++++++++++++ content/links/go-xml-vulnerability.pt.md | 81 ++++++++++++++++++++++++ 2 files changed, 159 insertions(+) create mode 100644 content/links/go-xml-vulnerability.md create mode 100644 content/links/go-xml-vulnerability.pt.md diff --git a/content/links/go-xml-vulnerability.md b/content/links/go-xml-vulnerability.md new file mode 100644 index 0000000..a209ec0 --- /dev/null +++ b/content/links/go-xml-vulnerability.md @@ -0,0 +1,78 @@ ++++ +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. + + + +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 hug 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. diff --git a/content/links/go-xml-vulnerability.pt.md b/content/links/go-xml-vulnerability.pt.md new file mode 100644 index 0000000..a7931af --- /dev/null +++ b/content/links/go-xml-vulnerability.pt.md @@ -0,0 +1,81 @@ ++++ +title = "Link Comentado: Coordinated disclosure of XML round-trip vulnerabilities in Go’s standard library" +date = 2020-12-14 + +[taxonomies] +tags = ["links", "go", "google", "golang", "xml", "vulnerabilidade"] ++++ + +Mattermost, junto com o Google, anunciou a [vulnerabilidade na +biblioteca XML padrão do +Go](https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities). Tem +algumas coisas que precisam ser examinadas nesse anúncio. + + + +Antes de mais nada, eu preciso avisar que eu nunca gostei de Go. Eu +não gosto da forma como a organização lida com a comunidade, eu não +gosto da forma como são lidados com os erros, e eu não gosto do estilo +de código que eles usam. Eu uso qualquer oportunidade para xingar a +linguagem. Mas dessa vez, eu acho que a coisa ficou tão errada que não +tem como não falar mal. + +Primeiro, ok, tem uma vulnerabilidade na biblioteca de XML. A +vulnerabilidade em si não é grande coisa -- basicamente, o que +acontece é que a biblioteca não mantém a ordem dos elementos conforme +a entrada -- mas o seu uso em coisas maiores, como o SAML, afeta a +forma como elas são liadas. Basicamente, algo que parece um XML/SAML +bem formado vai ser interpretado da forma errada porque o sistema está +mudando a semântica da coisa por mudar a ordem dos elementos. + +Segundo, desde que a vulnerabilidade foi encontrada, o time de +segurança do go estava trabalhando na correção, sem sucesso. A solução +depois disso foi que "a causa raiz da vulnerabilidade não pode ser +corrigida de forma confiável." Isso quer dizer que a biblioteca padrão +agora tem uma vulnerabilidade que não pode ser corrigida. + +Terceiro, essa vulnerabilidade foi encontrada em agosto deste ano e só +agora, quatro meses depois, a vulnerabilidade foi divulgada e +anunciada que não pode ser corrigida. Isso é bem enfurecedor porque o +Google tem um projeto chamado "Project Zero", criado para encontrar e +relatar falhas de seguranças em vários produtos. O problema é que essa +é a terceira vulnerabilidade não-tão-pequena no código do go e nenhuma +delas foi encontrada pelo Project Zero. Por outro lado, eles são bem +rápidos para encontrar e apontar -- depois de um prazo de 30 dias -- +problemas no Windows e no iOS, por exemplo. + +Ah, e caso você esteja se perguntando quais foram essas outras +vulnerabilidades: a primeira era relacionada com [bibliotecas +criptográficas](https://twitter.com/peter_szilagyi/status/1332047468004077569) +e basicamente afetou aplicações que usam Etherium. A segunda foi um +problema com a biblioteca "http", que poderia levar a uma [negação de +serviço no +Kubernete](https://www.bleepingcomputer.com/news/security/severe-flaws-in-kubernetes-expose-all-servers-to-dos-attacks/). + +Ainda... Quatro meses e nada de solução? Isso dá a sensação de que tem +algo seriamente errado com a arquitetura interna da linguagem, que +não permite que algo como ordenação seja aplicada. + +Mas de volta ao problema inicial: Quarto, a empresa que trabalhou com +o Google e ajudou a tentar corrigir o problema apontam que eles não +acreditam que a solução apresentada pelo time do go vai realmente +corrigir o problema. Nas palavras deles, parece que o Google só quer +jogar o problema pra baixo do tapete e, quando a coisa explicar, eles +possam dizer "é seu problema, nós avisamos". + +A solução do Google é, basicamente, "nós vamos botar na documentação e +esperar pelo menor". Então, sem correção de verdade. Honestamente, a +solução correta nesse caso seria remover a coisa toda e deixar alguém, +por sorte mais inteligente, escrever uma biblioteca XML correta. Nós +dizemos que nenhuma documentação é melhor que uma documentação errada, +então nenhuma biblioteca XML é melhor que uma biblioteca XML +vulnerável. + +Outra solução seria criar bindings para a libxml2, que é uma +biblioteca em C que serve como base para as necessidades de XML de +outras linguagens. Isso significaria que a biblioteca padrão do go +necessitaria outras bibliotecas para ser construída. + +Pessoalmente, com tudo que tem acontecido com a linguagem, usar a +mesma para qualquer projeto semi-sério (ou superior) é completamente +estúpido.