In den Sammlung der Kryptographiebibliotheken NSS (Network Security Services), die von Mozilla entwickelt werden, wurde eine kritische Schwachstelle (CVE-2021-43527) entdeckt, die zu einer Ausführung von Schadcode führen kann, wenn digitale Signaturen DSA oder RSA-PSS verarbeitet werden, die mit der Kodierungsmethode DER (Distinguished Encoding Rules) festgelegt wurden. Das Problem, das den Codenamen BigSig trägt, wurde in den Versionen NSS 3.73 und NSS ESR 3.68.1 behoben. Paketaktualisierungen sind für die Distributionen Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo und FreeBSD verfügbar. Für Fedora sind bisher keine Updates verfügbar.
Das Problem tritt in Anwendungen auf, die NSS zur Verarbeitung digitaler Signaturen CMS, S/MIME, PKCS #7 und PKCS #12 verwenden, oder bei der Überprüfung von Zertifikaten in TLS-, X.509-, OCSP- und CRL-Implementierungen. Die Schwachstelle kann in verschiedenen Client- und Serveranwendungen mit Unterstützung für TLS, DTLS und S/MIME sowie in E-Mail-Clients und PDF-Viewer-Programmen auftreten, die den NSS-Aufruf CERT_VerifyCertificate() zur Überprüfung digitaler Signaturen verwenden.
Beispiele für anfällige Anwendungen sind LibreOffice, Evolution und Evince. Potenziell kann 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-Webserver, Oracle Communications Messaging Server und Oracle Directory Server Enterprise Edition betreffen. Die Schwachstelle tritt hingegen nicht in Firefox, Thunderbird und Tor Browser auf, die eine separate Bibliothek mozilla::pkix zur Überprüfung verwenden, die ebenfalls Teil von NSS ist. Auch Chromium-basierte Browser sind nicht betroffen (es sei denn, sie wurden speziell mit NSS zusammengestellt), die bis 2015 NSS verwendeten, aber dann auf BoringSSL umgestellt wurden.
Die Schwachstelle wird durch einen Fehler im Zertifikatsüberprüfungscode in der Funktion vfy_CreateContext aus der Datei secvfy.c verursacht. Der Fehler tritt sowohl beim Lesen des Clientzertifikats vom Server als auch bei der Verarbeitung auf. Server von Clientzertifikaten. Während der Überprüfung einer digital signierten Nachricht, die mit der DER-Methode kodiert ist, decodiert NSS die Signatur in einen Puffer mit fester Größe und übergibt diesen Puffer an das PKCS #11-Modul. Bei der weiteren Verarbeitung wird die Größe für DSA- und RSA-PSS-Signaturen nicht korrekt überprüft, was zu einem Pufferüberlauf führt, der für die Struktur VFYContextStr reserviert ist, wenn die Größe der digitalen Signatur 16384 Bit überschreitet (für den Puffer werden 2048 Bytes reserviert, aber es wird nicht überprüft, ob die Signatur größer sein könnte).
Der anfällige Code wird seit 2003 verfolgt, stellte jedoch bis zur Umstrukturierung im Jahr 2012 keine Bedrohung dar. 2017 wurde beim Implementieren der Unterstützung für RSA-PSS derselbe Fehler gemacht. Für einen Angriff ist keine ressourcenintensive Generierung bestimmter Schlüssel erforderlich, um die benötigten Daten zu erhalten, da das Überlaufen bereits vor der Überprüfung der Gültigkeit der digitalen Signatur auftritt. Der überlaufende Teil der Daten wird in einen Speicherbereich geschrieben, der Zeiger auf Funktionen enthält, was die Erstellung funktionsfähiger Exploits erleichtert.
Die Schwachstelle wurde von Forschern des Google Project Zero im Rahmen von Experimenten mit neuen Fuzzing-Tests entdeckt und ist ein gutes Beispiel dafür, wie triviale Schwachstellen in einem umfangreich getesteten, bekannten Projekt lange unentdeckt bleiben können:
- Der NSS-Code wird von einem erfahrenen Sicherheitsteam begleitet, das moderne Test- und Fehleranalysemethoden anwendet. Es gibt mehrere Programme zur Auszahlung erheblicher Belohnungen für die Entdeckung von Schwachstellen in NSS.
- NSS war eines der ersten Projekte, das sich der Initiative Google oss-fuzz anschloss und wurde auch im von Mozilla entwickelten Fuzzing-Testsystem auf Basis von libFuzzer getestet.
- Der Code der Bibliothek wurde mehrfach durch verschiedene statische Analysewerkzeuge überprüft, einschließlich der Überwachung durch Coverity seit 2008.
- Bis 2015 wurde NSS in Google Chrome verwendet und unabhängig von Mozilla von Google getestet (seit 2015 wechselte Chrome zu BoringSSL, aber die Unterstützung für den NSS-basierten Port bleibt bestehen).
Die Hauptprobleme, warum das Problem lange Zeit unentdeckt blieb:
- NSS ist eine modulare Bibliothek, und Fuzzing-Tests wurden nicht insgesamt durchgeführt, sondern auf der Ebene einzelner Komponenten. Zum Beispiel wurde der Code zur Dekodierung von DER und zur Verarbeitung von Zertifikaten separat getestet – im Rahmen des Fuzzing könnte ein Zertifikat erhalten worden sein, das zur Manifestation der betrachteten Schwachstelle führt, aber dessen Überprüfung erreichte den Validierungscode nicht, sodass das Problem unentdeckt blieb.
- Bei der Fuzzing-Testdurchführung wurden strenge Beschränkungen für die Ausgabegröße (10.000 Byte) festgelegt, während es im NSS (Network Security Services) keine solchen Beschränkungen gab (viele Strukturen konnten im normalen Betrieb größer als 10.000 Byte sein, weshalb ein größeres Volumen an Eingabedaten erforderlich war, um Probleme zu identifizieren). Zur vollständigen Überprüfung musste das Limit 224-1 Byte (16 MB) betragen, was der maximalen Größe eines in TLS zugelassenen Zertifikats entspricht.
- Falsche Vorstellung über die Codeabdeckung durch Fuzzing-Tests. Der verwundbare Code wurde aktiv getestet, jedoch mithilfe von Fuzzern, die nicht in der Lage waren, die erforderlichen Eingabedaten zu generieren. Zum Beispiel verwendete der Fuzzer tls_server_target ein vordefiniertes Set von vorgefertigten Zertifikaten, was die Überprüfung des Zertifikatsverifizierungscodes auf TLS-Nachrichten und Zustandsänderungen im Protokoll beschränkte.
Quelle: opennet.ru
