Sicherheitslücke bei der Codeausführung in Mozilla NSS bei der Verarbeitung von Zertifikaten

In den von Mozilla entwickelten kryptografischen Bibliotheken NSS (Network Security Services) wurde eine kritische Schwachstelle (CVE-2021-43527) identifiziert, die zur Ausführung von Angreifercode bei der Verarbeitung digitaler DSA- oder RSA-PSS-Signaturen führen kann, die mit angegeben werden DER-Kodierungsmethode (Distinguished Encoding Rules). Das Problem mit dem Codenamen BigSig wurde in NSS 3.73 und NSS ESR 3.68.1 behoben. Paketaktualisierungen in Distributionen sind für Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD verfügbar. Für Fedora sind noch keine Updates verfügbar.

Das Problem tritt in Anwendungen auf, die NSS zur Verarbeitung digitaler CMS-, S/MIME-, PKCS #7- und PKCS #12-Signaturen verwenden, oder bei der Überprüfung von Zertifikaten in TLS-, X.509-, OCSP- und CRL-Implementierungen. Die Schwachstelle kann in verschiedenen Client- und Serveranwendungen auftreten, die TLS, DTLS und S/MIME unterstützen, sowie in E-Mail-Clients und PDF-Viewern, die den NSS CERT_VerifyCertificate()-Aufruf zur Überprüfung digitaler Signaturen verwenden.

Als Beispiele für anfällige Anwendungen werden LibreOffice, Evolution und Evince genannt. Möglicherweise betrifft 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. Allerdings taucht die Schwachstelle nicht in den Browsern Firefox, Thunderbird und Tor auf, die zur Überprüfung eine separate mozilla::pkix-Bibliothek verwenden, die ebenfalls in NSS enthalten ist. Chromium-basierte Browser (sofern sie nicht speziell mit NSS erstellt wurden), die bis 2015 NSS nutzten, dann aber auf BoringSSL umstiegen, sind von dem Problem ebenfalls nicht betroffen.

Die Sicherheitslücke wird durch einen Fehler im Zertifikatsüberprüfungscode in der Funktion vfy_CreateContext aus der Datei secvfy.c verursacht. Der Fehler tritt sowohl auf, wenn der Client ein Zertifikat vom Server liest, als auch wenn der Server Client-Zertifikate verarbeitet. Bei der Überprüfung einer DER-codierten digitalen Signatur dekodiert NSS die Signatur in einen Puffer fester Größe und übergibt den Puffer an das PKCS #11-Modul. Bei der weiteren Verarbeitung wird die Größe für DSA- und RSA-PSS-Signaturen falsch überprüft, was zu einem Überlauf des für die VFYContextStr-Struktur zugewiesenen Puffers führt, wenn die Größe der digitalen Signatur 16384 Bits überschreitet (für den Puffer sind jedoch 2048 Bytes zugewiesen). es wird nicht geprüft, ob die Signatur größer sein kann) ).

Der Code, der die Schwachstelle enthielt, lässt sich bis ins Jahr 2003 zurückverfolgen, stellte jedoch bis zu einer Umgestaltung im Jahr 2012 keine Bedrohung dar. Im Jahr 2017 wurde der gleiche Fehler bei der Implementierung der RSA-PSS-Unterstützung gemacht. Um einen Angriff durchzuführen, ist keine ressourcenintensive Generierung bestimmter Schlüssel erforderlich, um die erforderlichen Daten zu erhalten, da der Überlauf bereits in der Phase vor der Überprüfung der Richtigkeit der digitalen Signatur erfolgt. Der Teil der Daten, der über die Grenzen hinausgeht, wird in einen Speicherbereich geschrieben, der Zeiger auf Funktionen enthält, was die Erstellung funktionierender Exploits vereinfacht.

Die Schwachstelle wurde von Forschern des Google Project Zero beim Experimentieren mit neuen Fuzzing-Testmethoden entdeckt und ist ein gutes Beispiel dafür, wie triviale Schwachstellen in einem weithin getesteten bekannten Projekt lange Zeit unentdeckt bleiben können:

• Der NSS-Code wird von einem erfahrenen Sicherheitsteam mithilfe modernster Test- und Fehleranalysetechniken gepflegt. Es gibt mehrere Programme, die erhebliche Belohnungen für die Identifizierung von Schwachstellen in NSS zahlen.
• NSS war eines der ersten Projekte, das sich der Oss-Fuzz-Initiative von Google anschloss und wurde auch in Mozillas libFuzzer-basiertem Fuzz-Testsystem getestet.
• Der Bibliothekscode wurde viele Male in verschiedenen statischen Analysegeräten überprüft, unter anderem seit 2008 durch den Coverity-Dienst.
• Bis 2015 wurde NSS in Google Chrome verwendet und vom Google-Team unabhängig von Mozilla unabhängig verifiziert (seit 2015 wechselte Chrome zu BoringSSL, die Unterstützung für den NSS-basierten Port bleibt jedoch bestehen).

Die Hauptprobleme, aufgrund derer das Problem lange Zeit unentdeckt blieb:

• Die modulare NSS-Bibliothek und die Fuzzing-Tests 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 überprüft. Beim Fuzzing hätte man ein Zertifikat erhalten können, das zur Manifestation der betreffenden Schwachstelle führen würde, aber bei der Prüfung wurde der Verifizierungscode nicht erreicht, und das Problem trat nicht auf sich offenbaren.
• Während des Fuzzing-Tests wurden strenge Einschränkungen für die Ausgabegröße (10000 Byte) festgelegt, da es in NSS keine ähnlichen Einschränkungen gab (viele Strukturen im Normalmodus könnten eine Größe von mehr als 10000 Byte haben, daher waren mehr Eingabedaten erforderlich, um Probleme zu identifizieren). . Für eine vollständige Überprüfung hätte der Grenzwert 224-1 Byte (16 MB) betragen müssen, was der maximal zulässigen Zertifikatsgröße in TLS entspricht.
• Missverständnis über die Codeabdeckung von Fuzz-Tests. Der anfällige Code wurde aktiv getestet, jedoch mithilfe von Fuzzern, die nicht in der Lage waren, die erforderlichen Eingabedaten zu generieren. Fuzzer tls_server_target verwendete beispielsweise einen vordefinierten Satz vorgefertigter Zertifikate, wodurch die Überprüfung des Zertifikatsverifizierungscodes nur auf TLS-Nachrichten und Protokollstatusänderungen beschränkt wurde.

Source: opennet.ru