Browse Source

Commented Link: vulnerability in go

master
Julio Biason 4 years ago
parent
commit
c16e73c50b
  1. 78
      content/links/go-xml-vulnerability.md
  2. 81
      content/links/go-xml-vulnerability.pt.md

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

81
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.
Loading…
Cancel
Save