blog/content/links/go-xml-vulnerability.pt.md

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

PS: Logo depois que eu postei esse artigo, eu recebi um aviso que o
time do go anunciou uma nova versão que corrige uma vulnerabilidade na
biblioteca "ssh" da stdlib. Mais uma vez, usar go para um projeto que
é pelo menos semi-sério é estupidez.