GnuTLS corrige bug de má gestão de memória – atualize agora!

A biblioteca criptográfica mais conhecida no mundo de código aberto é quase certamente OpenSSL.

Em primeiro lugar, é um dos mais usados, a ponto de a maioria dos desenvolvedores na maioria das plataformas já terem ouvido falar dele, mesmo que não o tenham usado diretamente.

Em segundo lugar, é provavelmente o mais amplamente divulgado, infelizmente por causa de um bug bastante desagradável conhecido como heartbleed que foi descoberto há mais de oito anos.

Apesar de ter sido corrigido prontamente (e apesar das soluções confiáveis ​​existentes para desenvolvedores que não podiam ou não atualizaram suas versões vulneráveis ​​do OpenSSL rapidamente), o Heartbleed continua sendo uma espécie de bug de “vitrine”, até porque foi um dos primeiros bugs a ser transformado em um veículo de relações públicas agressivo por seus descobridores.

Com um nome impressionante, um logotipo próprio e um site dedicado, o Heartbleed rapidamente se tornou uma empresa global de segurança cibernética super-história, e, para o bem ou para o mal, tornou-se inextricavelmente ligado às menções ao nome OpenSSL, como se o perigo do bug continuasse mesmo depois de ter sido extirpado do código.

Vida além do OpenSSL

Mas existem várias outras bibliotecas criptográficas de código aberto que são amplamente usadas assim como ou em vez do OpenSSL, incluindo a Mozilla's NSS (abreviatura de Serviços de segurança de rede) e o projeto GNU gnuTLS biblioteca.

Acontece que o GnuTLS acabou de corrigir um bug conhecido como CVE-2022-2509, informado no projeto assessoria de segurança GNUTLS-SA-2022-07-07.

Este patch corrige um erro de má gestão de memória conhecido como duplamente grátis.

Explicação duplamente livre

Simplificando, uma vulnerabilidade double-free é criada quando um programador pede ao sistema operacional para alocar um bloco de memória para usar temporariamente…

…e o devolve para que possa ser excluído da lista de blocos emprestados para serem liberados para uso por outras partes do programa…

…e então acidentalmente pede ao sistema para liberar o mesmo bloco de memória novamente.

Idealmente, o software de alocação de memória detectará que o bloco não pertence mais à parte do programa que o está “retornando”, descobrirá que o bloco incorreto já foi reciclado e não o desalocará uma segunda vez, evitando assim os riscos de “libertá-lo” novamente.

Lidar com cuidado com um double free que é detectado proativamente é um problema complicado. A função C que devolve a memória é prototipada como void free(void *ptr); para que você passe o endereço de um bloco que deseja liberar, mas não receba de volta um código de retorno. (função AC com void valor de retorno é o que outras linguagens de programação chamam de procedure: ele faz algo para você, mas não tem como relatar um resultado.) Assim, mesmo o código C cuidadosamente escrito não tem uma maneira padrão de detectar que algo deu errado no free(), e, portanto, não há como lidar com o erro tentando desligar normalmente. Terminar unilateralmente o programa ofensivo é a única solução segura para o sistema.

Mas se a alocação de memória não perceber (talvez porque esse mesmo bloco tenha sido entregue a outra parte do mesmo programa, então ele está de volta na lista de “empréstimos” exatamente da mesma forma que era antes) , então é provável que coisas ruins aconteçam.

Notavelmente, o gerenciador de memória pode inadvertida e inesperadamente “confiscar” o bloco duplamente liberado do código que agora está usando-o legitimamente e reatribuí-lo a outra parte do programa, talvez até mesmo código malicioso que um invasor tenha cronometrado cuidadosamente para aproveitar da má gestão.

Então, você pode acabar com duas partes do mesmo programa manipulando o mesmo pedaço de memória.

Uma parte do programa assume que pode confiar implicitamente no conteúdo da memória, pois se considera o legítimo “dono” do bloco.

Ao mesmo tempo, outra parte do programa sabe que pode mexer com os dados (ou pode ser enganada para mexer com eles) para enganar a primeira parte deliberadamente.

Fazer a coisa errada faz a coisa certa

Ironicamente, o bug CVE-2022-2509 existe no código de verificação do certificado no GnuTLS.

(A ironia, caso você esteja se perguntando, é que o software que é inseguro em geral porque não se preocupa em verificar conexões TLS confiáveis ​​é imune a esse bug de segurança específico.)

Por exemplo, quando você visita um site (ou outro tipo de servidor) protegido com TLS, a outra extremidade normalmente envia um certificado da Web que afirma que o servidor realmente pertence e é operado pela organização que você espera.

É claro que, dado que qualquer pessoa pode criar um certificado com o nome que quiser, um certificado bruto por si só não diz muito, então o proprietário do certificado geralmente o assina digitalmente por uma empresa na qual seu navegador já confia.

Na prática, os certificados geralmente são assinados por um certificado que, por sua vez, é assinado por um certificado no qual seu navegador confia, mas o resultado final é o que chamamos de cadeia de confiança que pode ser rastreado com segurança para um certificado que já está instalado em uma lista dos chamados Autoridades confiáveis, também conhecido como Raízes, que é gerenciado pelo seu navegador ou sistema operacional.

Para simplificar e acelerar o processo de validação da cadeia de certificados, muitos servidores não apenas enviam seu próprio certificado e deixam que o navegador “persegue a cadeia” até uma raiz confiável.

O servidor normalmente inclui a cadeia de confiança na qual está confiando, que ele só precisa construir uma vez, para que seu navegador, ou qualquer software que esteja verificando o certificado, possa simplesmente verificar se a cadeia é digitalmente válida e, em seguida, verificar se o último certificado na cadeia corresponde a um que já é confiável.

Nesse caso, o GnuTLS validará corretamente e com segurança o certificado fornecido, antes de liberar o bloco de memória usado para armazená-lo.

Mas se a outra extremidade não fornecer uma cadeia de certificados pré-gerada, deixando o GnuTLS para criar e verificar a cadeia por conta própria, o código GnuTLS acidentalmente libera a memória usada para armazenar o certificado fornecido antes de iniciar a cadeia. processo de verificação…

…e, em seguida, libera-o novamente após a conclusão da verificação.

Isso causa um acidente duplo livre, o que pode levar à corrupção de memória, seguida por uma falha do programa.

Pastorear uma falha para implantar malware

Normalmente, ou pelo menos frequentemente, travamentos causam um comportamento tão instável que o sistema operacional detecta que o programa incorreto perdeu o controle do fluxo de execução do programa – por exemplo, se o programa salta para um endereço de memória aleatório e tenta executar o código de um bloco de memória que não foi alocado.

Nesse caso, o travamento provocaria um erro de sistema e, embora esse tipo de bug possa ser abusado para o que é chamado de Denial of Service (DoS), onde todo o objetivo é simplesmente interromper o programa que está sendo atacado, isso não leva a Execução Remota de Código (RCE), onde o código de software não confiável e indesejado é acionado.

Mas sempre que há uma falha de programa que os invasores podem provocar à vontade, com base em dados não confiáveis ​​que eles mesmos forneceram, há sempre o risco de que a falha possa ser conduzida de forma a direcionar mal o programa travado para que ele salte para o código executável fornecido pelos atacantes.

Como você pode imaginar, os invasores geralmente podem explorar essas vulnerabilidades para implantar malware, temporária ou permanentemente, uma vez que conseguem injetar código não confiável em seu computador sem produzir avisos pop-up pedindo permissão primeiro.

O que fazer?

Atualize para o última versão do GnuTLS, que é 3.7.7 no momento da escrita.

(Este bug aparentemente foi introduzido no GnuTLS 3.6.0, e existe em todas as versões desde então, até e incluindo 3.7.6.)

Observe que muitos aplicativos populares e kits de ferramentas de programação incluem ou podem ser criados para fazer uso do GnuTLS, mesmo que você não esteja ciente disso, incluindo, mas não limitado a: FFmpeg, GnuPG, Mplayer, QEMU, Rdesktop, Samba, Wget, Wireshark e Zlib.

Muitos pacotes Linux ou *BSD que usam GnuTLS dependem de uma versão central gerenciada por sua própria distribuição, portanto, certifique-se de atualizar assim que sua distribuição tiver essa versão disponível.

Feliz remendo!

---