BigSig, une vulnérabilité dans Mozilla NSS qui pourrait permettre l'exécution de code

Les nouvelles sur identifier une vulnérabilité critique (déjà répertorié sous CVE-2021-43527) en l'ensemble des librairies cryptographiques NSS (Services de sécurité réseau) de Mozilla pouvant conduire à l'exécution de code malveillant lors du traitement des signatures numériques DSA ou RSA-PSS spécifiées à l'aide de DER (Distinguished Encoding Rules).

Le problème se manifeste dans les applications qui utilisent NSS pour gérer les signatures numériques CMS, S/MIME, PKCS#7 et PKCS#12, ou lors de la vérification des certificats dans les déploiements TLS, X.509, OCSP et CRL. La vulnérabilité pourrait survenir dans diverses applications client et serveur avec prise en charge TLS, DTLS et S/MIME, les clients de messagerie et les visionneuses PDF qui utilisent l'appel NSS CERT_VerifyCertificate () pour vérifier les signatures numériques.

LibreOffice, Evolution et Evince sont cités comme exemples d'applications vulnérables. Potentiellement, le problème peut également affecter des projets tels que Pidgin, Apache OpenOffice, Suricata, Curl, entre autres.

En même temps, la vulnérabilité n'apparaît pas dans Firefox, Thunderbird et Tor Browser, qui utilisent une bibliothèque mozilla :: pkix distincte pour la vérification, qui fait également partie de NSS. Les Navigateurs basés sur Chrome (sauf s'ils ont été spécifiquement compilés avec NSS), qui a utilisé NSS jusqu'en 2015, mais a ensuite été transféré à BoringSSL, ils ne sont pas concernés par le problème.

La vulnérabilité est due à un bogue dans le code de vérification du certificat dans le vfy_CreateContext fonction du fichier secvfy.c. L'erreur se manifeste à la fois lorsque le client lit le certificat du serveur comme lorsque le serveur traite les certificats du client.

Lors de la vérification d'une signature numérique codée DER, NSS décode la signature dans un tampon de taille fixe et transmet ce tampon au module PKCS # 11. Pendant le post-traitement, pour les signatures DSA et RSA-PSS, la taille est mal vérifiée, ce qui entraîne qui conduit à un débordement du buffer alloué pour la structure VFYContextStr, si la taille de la signature numérique dépasse 16384 bits (2048 octets sont alloués pour le buffer, mais il n'est pas vérifié que la signature peut être plus grande).

Le code qui contient la vulnérabilité date de 2003, mais ce n'était pas une menace jusqu'à la refactorisation en 2012. En 2017, la même erreur a été commise lors de la mise en œuvre du support RSA-PSS. Pour mener une attaque, une génération gourmande en ressources de certaines clés n'est pas nécessaire pour obtenir les données nécessaires, puisque le débordement se produit dans l'étape précédant la vérification de la validité de la signature numérique. La partie hors limites des données est écrite dans une zone de mémoire qui contient des pointeurs de fonction, ce qui facilite la création d'exploits fonctionnels.

La vulnérabilité a été identifiée par les chercheurs de Google Project Zero lors d'expériences avec de nouvelles méthodes de test de fuzzing et est une bonne démonstration de la façon dont des vulnérabilités insignifiantes peuvent passer inaperçues pendant longtemps dans un projet connu largement testé.

En ce qui concerne principaux problèmes pour lesquels le problème est passé inaperçu pendant très longtemps:

  • La bibliothèque de lecteurs NSS et les tests de fuzzing n'ont pas été effectués dans leur intégralité, mais au niveau des composants individuels.
  • Par exemple, le code pour décoder le DER et les certificats de traitement a été vérifié séparément ; Au cours du fuzzing, un certificat aurait bien pu être obtenu, conduisant à la manifestation de la vulnérabilité en question, mais sa vérification n'a pas atteint le code de vérification et le problème n'a pas été révélé.
  • Au cours des tests de fuzzing, des limites strictes ont été fixées sur la taille de la sortie (10,000 10,000 octets) en l'absence de telles limitations dans NSS (de nombreuses structures en mode normal pourraient être supérieures à 2 24 octets, donc, pour identifier les problèmes, plus de données d'entrée nécessaires ). Pour une vérification complète, la limite aurait dû être de 1 16 -XNUMX octets (XNUMX Mo), ce qui correspond à la taille maximale d'un certificat autorisée dans TLS.
  • Idée fausse sur la couverture du code par les tests de fuzz. Le code vulnérable a été testé activement, mais à l'aide de fuzers, qui n'ont pas été en mesure de générer les données d'entrée requises. Par exemple, fuzzer tls_server_target utilisait un ensemble prédéfini de certificats prêts à l'emploi, qui limitait la vérification du code de vérification du certificat aux seuls messages TLS et aux changements d'état du protocole.

Enfin, Il convient de mentionner que le problème avec le nom de code BigSig a été corrigé dans NSS 3.73 et NSS ESR 3.68.1 et les mises à jour de la solution sous forme de package ont déjà été publiées dans les différentes distributions : Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.

Si vous souhaitez en savoir plus, vous pouvez consulter le lien suivant.


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.