Commented Link: vulnerability in go

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.
+
+<!-- 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 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.

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.
+
+<!-- more -->
+
+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.