Uma vulnerabilidade crítica (CVE-2021-43527) foi identificada no conjunto de bibliotecas criptográficas NSS (Network Security Services) desenvolvido pela Mozilla, que pode levar à execução de código invasor ao processar assinaturas digitais DSA ou RSA-PSS especificadas usando o Método de codificação DER (Regras de Codificação Distintas). O problema, codinome BigSig, foi resolvido no NSS 3.73 e no NSS ESR 3.68.1. Atualizações de pacotes em distribuições estão disponíveis para Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Ainda não há atualizações disponíveis para o Fedora.
O problema ocorre em aplicações que utilizam NSS para lidar com assinaturas digitais CMS, S/MIME, PKCS #7 e PKCS #12, ou ao verificar certificados em implementações TLS, X.509, OCSP e CRL. A vulnerabilidade pode aparecer em vários aplicativos de cliente e servidor que suportam TLS, DTLS e S/MIME, clientes de e-mail e visualizadores de PDF que usam a chamada NSS CERT_VerifyCertificate() para verificar assinaturas digitais.
LibreOffice, Evolution e Evince são mencionados como exemplos de aplicações vulneráveis. Potencialmente, o problema também pode afetar projetos como Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss para o servidor Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. No entanto, a vulnerabilidade não aparece no Firefox, Thunderbird e Tor Browser, que usam uma biblioteca separada mozilla::pkix, também incluída no NSS, para verificação. Navegadores baseados em Chromium (a menos que sejam construídos especificamente com NSS), que usaram NSS até 2015, mas depois mudaram para BoringSSL, também não são afetados pelo problema.
A vulnerabilidade é causada por um erro no código de verificação do certificado na função vfy_CreateContext do arquivo secvfy.c. O erro ocorre quando o cliente lê um certificado do servidor e quando o servidor processa os certificados do cliente. Ao verificar uma assinatura digital codificada por DER, o NSS decodifica a assinatura em um buffer de tamanho fixo e passa o buffer para o módulo PKCS #11. Durante o processamento adicional, o tamanho é verificado incorretamente para assinaturas DSA e RSA-PSS, o que leva a um estouro do buffer alocado para a estrutura VFYContextStr se o tamanho da assinatura digital exceder 16384 bits (2048 bytes são alocados para o buffer, mas não é verificado se a assinatura pode ser maior)).
O código que contém a vulnerabilidade remonta a 2003, mas não representava uma ameaça até uma refatoração realizada em 2012. Em 2017, o mesmo erro foi cometido na implementação do suporte RSA-PSS. Para realizar um ataque, não é necessária a geração intensiva de recursos de determinadas chaves para obter os dados necessários, uma vez que o estouro ocorre na fase anterior à verificação da exatidão da assinatura digital. A parte dos dados que ultrapassa os limites é gravada em uma área de memória contendo ponteiros para funções, o que simplifica a criação de explorações funcionais.
A vulnerabilidade foi descoberta por pesquisadores do Google Project Zero enquanto experimentavam novos métodos de teste de difusão e é uma boa demonstração de como vulnerabilidades triviais podem passar despercebidas por um longo tempo em um projeto conhecido amplamente testado:
- O código NSS é mantido por uma equipe de segurança experiente, usando testes de última geração e técnicas de análise de erros. Existem vários programas em vigor para pagar recompensas significativas pela identificação de vulnerabilidades no NSS.
- O NSS foi um dos primeiros projetos a aderir à iniciativa oss-fuzz do Google e também foi testado no sistema de testes fuzz baseado em libFuzzer da Mozilla.
- O código da biblioteca foi verificado diversas vezes em diversos analisadores estáticos, inclusive monitorado pelo serviço Coverity desde 2008.
- Até 2015, o NSS era usado no Google Chrome e verificado de forma independente pela equipe do Google, independentemente da Mozilla (desde 2015, o Chrome mudou para BoringSSL, mas o suporte para a porta baseada em NSS permanece).
Os principais problemas pelos quais o problema permaneceu sem ser detectado por muito tempo:
- A biblioteca modular NSS e os testes de difusão não foram realizados como um todo, mas no nível de componentes individuais. Por exemplo, o código para decodificação de DER e processamento de certificados foi verificado separadamente - durante a difusão, poderia ter sido obtido um certificado que levaria à manifestação da vulnerabilidade em questão, mas sua verificação não atingiu o código de verificação e o problema não revelar-se.
- Durante o teste de difusão, restrições estritas foram definidas no tamanho de saída (10000 bytes) na ausência de restrições semelhantes no NSS (muitas estruturas no modo normal poderiam ter um tamanho de mais de 10000 bytes, portanto, mais dados de entrada eram necessários para identificar problemas) . Para verificação completa, o limite deveria ser de 224-1 bytes (16 MB), o que corresponde ao tamanho máximo de certificado permitido em TLS.
- Equívoco sobre a cobertura do código de teste fuzz. O código vulnerável foi testado ativamente, mas usando fuzzers que não conseguiram gerar os dados de entrada necessários. Por exemplo, o fuzzer tls_server_target usou um conjunto predefinido de certificados prontos, que limitou a verificação do código de verificação do certificado apenas a mensagens TLS e alterações de estado do protocolo.
Fonte: opennet.ru