Julio Biason
4 years ago
2 changed files with 159 additions and 0 deletions
@ -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. |
@ -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…
Reference in new issue