Une vulnérabilité critique (CVE-2021-43527) a été identifiée dans les bibliothèques cryptographiques NSS (Network Security Services) développées par Mozilla. Elle pourrait permettre à un attaquant d'exécuter du code lors du traitement de signatures numériques DSA ou RSA-PSS spécifiées par le biais de la méthode d'encodage DER (Distinguished Encoding Rules). Ce problème, baptisé BigSig, a été corrigé dans les versions NSS 3.73 et NSS ESR 3.68.1. Les mises à jour des paquets pour les distributions sont disponibles pour Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo et FreeBSD. Les mises à jour pour Fedora ne sont pas encore disponibles.
Le problème se manifeste dans les applications utilisant NSS pour traiter des signatures numériques CMS, S/MIME, PKCS #7 et PKCS #12, ou lors de la vérification des certificats dans les implémentations TLS, X.509, OCSP et CRL. La vulnérabilité peut apparaître dans diverses applications clientes et serveurs prenant en charge TLS, DTLS et S/MIME, ainsi que dans les clients de messagerie et les lecteurs de PDF utilisant l'appel NSS CERT_VerifyCertificate() pour vérifier les signatures numériques.
Des exemples d'applications vulnérables incluent LibreOffice, Evolution et Evince. Potentiellement, le problème pourrait également concerner des projets tels que Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss pour le serveur http Apache, Oracle Communications Messaging Server et Oracle Directory Server Enterprise Edition. En revanche, Firefox, Thunderbird et Tor Browser ne sont pas affectés, car ils utilisent une bibliothèque distincte mozilla::pkix pour la verification, qui fait également partie de NSS. Les navigateurs basés sur Chromium ne sont pas non plus vulnérables (à moins qu'ils ne soient spécifiquement compilés avec NSS), ayant utilisé NSS jusqu'en 2015 avant d'adopter BoringSSL.
La vulnérabilité est causée par une erreur dans le code de vérification des certificats dans la fonction vfy_CreateContext du fichier secvfy.c. L'erreur se manifeste tant lors de la lecture du certificat client depuis le serveur que lors du traitement des certificats. serveur Lors de la vérification d'une signature numérique codée par la méthode DER, NSS décode la signature dans un tampon de taille fixe et transmet ce tampon au module PKCS #11. Lors du traitement ultérieur, pour les signatures DSA et RSA-PSS, la taille n'est pas correctement vérifiée, ce qui entraîne un débordement de tampon alloué pour la structure VFYContextStr, si la taille de la signature numérique dépasse 16384 bits (un tampon de 2048 octets est alloué, mais il n'est pas vérifié que la signature puisse être de plus grande taille).
Le code contenant une vulnérabilité est traçable depuis 2003, mais il ne représentait pas de menace avant le refactoring effectué en 2012. En 2017, lors de la mise en œuvre du support RSA-PSS, la même erreur a été commise. Pour effectuer une attaque, il n'est pas nécessaire de générer des clés spécifiques de manière gourmande en ressources pour obtenir les données requises, car le dépassement de mémoire se produit à un stade antérieur à la vérification de la validité de la signature numérique. Une partie des données qui dépasse les limites est écrite dans une zone mémoire contenant des pointeurs vers des fonctions, ce qui facilite la création d'exploits fonctionnels.
La vulnérabilité a été détectée par des chercheurs de Google Project Zero lors d'expérimentations avec de nouvelles méthodes de test par fuzzing et constitue une bonne démonstration de la manière dont des vulnérabilités triviales peuvent rester inaperçues pendant longtemps dans un projet largement testé et bien connu :
- Le code NSS est accompagné d'une équipe expérimentée, responsable de la sécurité, qui applique des méthodes modernes de test et d'analyse des erreurs. Plusieurs programmes de récompense significative existent pour les découvertes de vulnérabilités dans NSS.
- NSS a été l'un des premiers projets à rejoindre l'initiative Google oss-fuzz et a également été testé dans le système de fuzzing développé par Mozilla basé sur libFuzzer.
- Le code de la bibliothèque a été vérifié à plusieurs reprises à l'aide de divers analyseurs statiques, notamment depuis 2008 via le service Coverity.
- Jusqu'en 2015, NSS était utilisé dans Google Chrome et, indépendamment de Mozilla, était vérifié par l'équipe de Google (depuis 2015, Chrome est passé à BoringSSL, mais le support du port basé sur NSS est maintenu).
Les principales raisons pour lesquelles le problème est resté inaperçu pendant longtemps :
- NSS est une bibliothèque modulaire et le fuzzing a été réalisé non pas dans son ensemble, mais au niveau de composants individuels. Par exemple, le code de décodage DER et de traitement des certificats était vérifié séparément — lors du fuzzing, il était tout à fait possible d'obtenir un certificat entraînant l'apparition de la vulnérabilité discutée, mais sa vérification ne parvenait pas au code de vérification et le problème ne se manifestait pas.
- Lors des tests de fuzzing, des limites strictes étaient imposées à la taille de la sortie (10 000 octets), alors qu'aucune telle restriction n'existait dans NSS (beaucoup de structures en mode normal pouvaient avoir une taille supérieure à 10 000 octets, ce qui nécessitait un volume d'entrée plus important pour identifier les problèmes). Pour un test complet, la limite devait être de 224-1 octets (16 Mo), ce qui correspond à la taille maximale du certificat autorisée dans TLS.
- Représentation incorrecte de la couverture du code par les tests de fuzzing. Le code vulnérable a été activement testé, mais à l'aide de fuzzers incapables de générer les données d'entrée nécessaires. Par exemple, le fuzzer tls_server_target utilisait un ensemble prédéfini de certificats, ce qui limitait le test du code de vérification des certificats aux messages TLS et aux changements d'état du protocole.
Source : opennet.ru
