Link Comentado: Coordinated disclosure of XML round-trip vulnerabilities in Go’s standard library

Mattermost, junto com o Google, anunciou a vulnerabilidade na biblioteca XML padrão do Go. 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 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.

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.