In dem von Mozilla entwickelten Satz kryptografischer Bibliotheken NSS (Network Security Services) wurde eine kritische Schwachstelle (CVE-2021-43527) entdeckt, die dazu führen kann, dass beim Verarbeiten von digitalen Signaturen DSA oder RSA-PSS, die mit dem DER-Codierungsverfahren (Distinguished Encoding Rules) festgelegt wurden, Schadcode ausgeführt wird. Das Problem, das den Codenamen BigSig trägt, wurde in den Versionen NSS 3.73 und NSS ESR 3.68.1 behoben. Aktualisierungen für Distributionen sind für Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo und FreeBSD verfügbar. Aktuell sind keine Updates für Fedora verfügbar.
Das Problem tritt in Anwendungen auf, die NSS zur Verarbeitung von digitalen Signaturen CMS, S/MIME, PKCS #7 und PKCS #12 verwenden oder bei der Überprüfung von Zertifikaten in Implementierungen von TLS, X.509, OCSP und CRL. Die Schwachstelle kann in verschiedenen Client- und Serveranwendungen auftreten, die TLS, DTLS und S/MIME unterstützen, sowie in E-Mail-Clients und PDF-Readern, die den NSS-Aufruf CERT_VerifyCertificate() zur Überprüfung digitaler Signaturen verwenden.
Als Beispiele für anfällige Anwendungen werden LibreOffice, Evolution und Evince genannt. Potenziell könnte das Problem auch Projekte wie Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss für den Apache HTTP-Server, Oracle Communications Messaging Server und Oracle Directory Server Enterprise Edition betreffen. Die Schwachstelle zeigt sich jedoch nicht in Firefox, Thunderbird und Tor Browser, wo zur Verifizierung eine separate Bibliothek mozilla::pkix verwendet wird, die ebenfalls Bestandteil von NSS ist. Auch Chromium-basierte Browser sind nicht betroffen (sofern sie nicht speziell mit NSS kompiliert wurden), die bis 2015 NSS verwendet haben, aber dann auf BoringSSL umgestiegen sind.
Die Schwachstelle wird durch einen Fehler im Code der Zertifikatverifizierungsprüfung in der Funktion vfy_CreateContext aus der Datei secvfy.c verursacht. Der Fehler tritt sowohl beim Lesen des Zertifikats durch den Client vom Server als auch bei der Verarbeitung auf. dem Server durch Kunden-Zertifikate. Während der Überprüfung der mit DER-Methode codierten digitalen Signatur decodiert NSS die Signatur in einen festen Buffer und überträgt diesen Buffer an das PKCS #11-Modul. Bei der weiteren Verarbeitung wird die Größe der Signaturen für DSA und RSA-PSS inkorrekt überprüft, was zu einem Pufferüberlauf führt, wenn die Größe der digitalen Signatur 16.384 Bit überschreitet (da 2.048 Byte für den Puffer reserviert sind, jedoch nicht überprüft wird, dass die Signatur größer sein kann).
Der Code mit der Sicherheitsanfälligkeit ist seit 2003 bekannt, stellte jedoch bis zur Refaktorisierung im Jahr 2012 keine Bedrohung dar. Bei der Implementierung der Unterstützung für RSA-PSS im Jahr 2017 wurde der gleiche Fehler gemacht. Für einen Angriff ist keine ressourcenintensive Generierung bestimmter Schlüssel erforderlich, um die benötigten Daten zu erhalten, da der Pufferüberlauf bereits vor der Überprüfung der Korrektheit der digitalen Signatur stattfindet. Der überlaufende Teil der Daten wird in einen Speicherbereich geschrieben, der Funktionszeiger enthält, was die Erstellung funktionsfähiger Exploits erleichtert.
Die Schwachstelle wurde von Forschern des Google Project Zero während Experimente mit neuen Methoden des Fuzzing-Tests entdeckt und stellt eine gute Demonstration dar, wie triviale Schwachstellen über einen längeren Zeitraum unentdeckt in einem umfassend getesteten, bekannten Projekt bleiben können.
- Der NSS-Code wird von einem erfahrenen Team begleitet, das für die Sicherheit verantwortlich ist und moderne Test- und Fehleranalysenmethoden anwendet. Es gibt mehrere Programme zur Zahlung erheblicher Belohnungen für die Entdeckung von Schwachstellen im NSS.
- NSS war eines der ersten Projekte, die sich an der Google-Initiative oss-fuzz beteiligten und wurde auch im von Mozilla entwickelten Fuzzing-Testsystem auf Basis von libFuzzer geprüft.
- Der Bibliothekscode wurde mehrfach durch verschiedene statische Analysatoren überprüft, darunter der Service Coverity seit 2008.
- Bis 2015 wurde NSS in Google Chrome verwendet und unabhängig von Mozilla vom Google-Team getestet (seit 2015 hat Chrome auf BoringSSL umgestellt, aber die Unterstützung für den NSS-basierten Port bleibt bestehen).
Die Hauptprobleme, die dazu führten, dass die Schwachstelle über einen längeren Zeitraum unentdeckt blieb:
- Die NSS-Modulbibliothek und das Fuzzing-Testing wurden nicht als Ganzes, sondern auf der Ebene einzelner Komponenten durchgeführt. Beispielsweise wurde der Code zur Dekodierung von DER und zur Verarbeitung von Zertifikaten separat getestet – im Verlauf des Fuzzing könnte ein Zertifikat generiert worden sein, das die diskutierte Sicherheitsanfälligkeit auslöst, jedoch wurde es nicht bis zum Verifikationscode geprüft, wodurch das Problem unentdeckt blieb.
- Beim Fuzzing-Testing wurden strenge Beschränkungen für die Ausgabegröße (10.000 Bytes) festgelegt, während solche Beschränkungen in NSS nicht vorhanden waren (viele Strukturen konnten im Normalbetrieb größer als 10.000 Bytes sein, was einen größeren Eingabedatenvolumen erforderte, um Probleme zu erkennen). Für eine umfassende Prüfung hätte das Limit 224-1 Bytes (16 MB) betragen müssen, was der maximalen Zertifikatgröße entspricht, die in TLS zulässig ist.
- Missverständnis über den Umfang des Fuzzing-Tests. Der anfällige Code wurde aktiv getestet, jedoch mit Fuzzern, die nicht in der Lage waren, die erforderlichen Eingabedaten zu generieren. Beispielsweise verwendete der Fuzzer tls_server_target einen vordefinierten Satz vordefinierter Zertifikate, was die Überprüfung des Zertifikatvalidierungscodes auf TLS-Nachrichten und den Statuswechsel des Protokolls beschränkte.
Quelle: opennet.ru
