BigSig, eine Schwachstelle in Mozilla NSS, die die Ausführung von Code ermöglichen könnte

Die Nachrichten über Identifizierung einer kritischen Schwachstelle (bereits gelistet unter CVE-2021-43527) en der Satz kryptografischer Bibliotheken NSS (Netzwerksicherheitsdienste) von Mozilla, die zur Ausführung von Schadcode führen könnten bei der Verarbeitung digitaler DSA- oder RSA-PSS-Signaturen, die mit DER (Distinguished Encoding Rules) spezifiziert sind.

Das Problem manifestiert sich in Anwendungen, die NSS verwenden, um digitale Signaturen zu verarbeiten CMS, S/MIME, PKCS # 7 und PKCS # 12, oder beim Überprüfen von Zertifikaten in Bereitstellungen TLS, X.509, OCSP und CRL. Die Sicherheitsanfälligkeit kann in verschiedenen Client- und Serveranwendungen mit TLS-, DTLS- und S/MIME-Unterstützung, E-Mail-Clients und PDF-Viewern auftreten, die den NSS CERT_VerifyCertificate()-Aufruf verwenden, um digitale Signaturen zu überprüfen.

Als Beispiele für anfällige Anwendungen werden LibreOffice, Evolution und Evince genannt. Potenziell kann das Problem auch Projekte wie Pidgin, Apache OpenOffice, Suricata, Curl und andere betreffen.

Zur gleichen Zeit die Schwachstelle taucht nicht in Firefox, Thunderbird und Tor Browser auf, die eine separate mozilla :: pkix-Bibliothek zur Verifizierung verwenden, die ebenfalls Teil von NSS ist. Die Chrome-basierte Browser (es sei denn, sie wurden speziell mit NSS kompiliert), das NSS bis 2015 verwendet, dann aber auf BoringSSL übertragen hat, Sie sind von dem Problem nicht betroffen.

Die Schwachstelle ist auf einen Fehler im Zertifikatsprüfcode im vfy_CreateContext zurückzuführen Funktion der Datei secvfy.c. Der Fehler manifestiert sich sowohl, wenn der Client das Zertifikat vom Server liest wenn der Server die Zertifikate des Clients verarbeitet.

Beim Verifizieren einer DER-codierten digitalen Signatur decodiert NSS die Signatur in einen Puffer fester Größe und übergibt diesen Puffer an das Modul PKCS Nr. 11. Während der Nachbearbeitung wird bei DSA- und RSA-PSS-Signaturen die Größe falsch verifiziert, was dazu führt, dass was zu einem Überlauf des zugewiesenen Puffers für die VFYContextStr-Struktur führt, wenn die Größe der digitalen Signatur 16384 Bit überschreitet (2048 Bytes werden für den Puffer zugewiesen, aber es wird nicht überprüft, dass die Signatur größer sein kann).

Der Code, der die Sicherheitsanfälligkeit enthält, stammt aus dem Jahr 2003, aber bis zum Refactoring im Jahr 2012 war es keine Bedrohung. 2017 wurde der gleiche Fehler bei der Implementierung der RSA-PSS-Unterstützung gemacht. Zur Durchführung eines Angriffs ist keine ressourcenintensive Generierung bestimmter Schlüssel erforderlich, um die erforderlichen Daten zu erhalten, da der Überlauf in der Phase vor der Überprüfung der Gültigkeit der digitalen Signatur erfolgt. Der außerhalb der Grenzen liegende Teil der Daten wird in einen Speicherbereich geschrieben, der Funktionszeiger enthält, wodurch es einfach ist, funktionierende Exploits zu erstellen.

Die Schwachstelle wurde von Google Project Zero-Forschern identifiziert bei Experimenten mit neuen Fuzzing-Testmethoden und ist eine gute Demonstration dafür, wie triviale Schwachstellen in einem erprobten bekannten Projekt lange Zeit unentdeckt bleiben können.

Wie für Hauptprobleme, bei denen das Problem unbemerkt blieb längst:

  • Die NSS-Laufwerkbibliotheks- und Fuzzing-Tests wurden nicht vollständig, sondern auf Einzelkomponentenebene durchgeführt.
  • Beispielsweise wurde der Code zur Dekodierung der DER- und Prozesszertifikate separat verifiziert; Im Zuge des Fuzzings könnte durchaus ein Zertifikat beschafft worden sein, das zur Manifestation der fraglichen Schwachstelle geführt hat, dessen Verifizierung jedoch nicht den Verifizierungscode erreichte und das Problem nicht aufgedeckt wurde.
  • Während der Fuzzing-Tests wurden der Größe der Ausgabe (10,000 Bytes) strenge Grenzen gesetzt, da solche Beschränkungen in NSS nicht vorhanden waren (viele Strukturen im normalen Modus könnten größer als 10,000 Byte sein, daher sind zur Identifizierung von Problemen mehr Eingabedaten erforderlich ). Für eine vollständige Verifizierung sollte das Limit 2 24 -1 Byte (16 MB) betragen haben, was der in TLS maximal zulässigen Größe eines Zertifikats entspricht.
  • Missverständnis bezüglich der Codeabdeckung durch Fuzzing-Tests. Der anfällige Code wurde aktiv getestet, jedoch mit Fuzern, die nicht in der Lage waren, die erforderlichen Eingabedaten zu generieren. Der Fuzzer tls_server_target verwendet beispielsweise einen vordefinierten Satz von sofort einsatzbereiten Zertifikaten, die die Überprüfung des Zertifikatsprüfcodes auf TLS-Nachrichten und Protokollstatusänderungen beschränkten.

Schließlich Es ist erwähnenswert, dass das Problem mit dem Codenamen BigSig in NSS 3.73 und NSS ESR 3.68.1 behoben wurde und die Updates der Lösung in Paketform wurden bereits in den verschiedenen Distributionen veröffentlicht: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.

Wenn Sie mehr darüber erfahren möchten, können Sie sich beraten den folgenden Link.


Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit *

*

*

  1. Verantwortlich für die Daten: AB Internet Networks 2008 SL
  2. Zweck der Daten: Kontrolle von SPAM, Kommentarverwaltung.
  3. Legitimation: Ihre Zustimmung
  4. Übermittlung der Daten: Die Daten werden nur durch gesetzliche Verpflichtung an Dritte weitergegeben.
  5. Datenspeicherung: Von Occentus Networks (EU) gehostete Datenbank
  6. Rechte: Sie können Ihre Informationen jederzeit einschränken, wiederherstellen und löschen.