Ernste Sicherheit: GnuTLS folgt OpenSSL, behebt Timing-Angriffsfehler

Letzte Woche haben wir über eine Menge geschrieben Speicherverwaltungsfehler die im neuesten Sicherheitsupdate der beliebten OpenSSL-Verschlüsselungsbibliothek behoben wurden.

Zusammen mit diesen Speicherfehlern haben wir auch über einen Fehler mit dem Titel „dubbed“ berichtet CVE-2022-4304: Timing Oracle bei der RSA-Entschlüsselung.

Bei diesem Fehler wird die gleiche verschlüsselte Nachricht immer wieder an einen Server gesendet, aber die Auffüllung am Ende der Daten geändert, um die Daten ungültig zu machen, und so ein unvorhersehbares Verhalten hervorrufen …

… würde nicht konstant viel Zeit in Anspruch nehmen, vorausgesetzt, Sie befinden sich in der Nähe des Ziels im Netzwerk und können zuverlässig abschätzen, wie lange der Datenübertragungsteil des Prozesses dauern würde.

Nicht alle Daten werden gleichermaßen verarbeitet

Wenn Sie eine Anfrage absetzen, die Zeit messen, wie lange die Antwort dauert, und die Zeit abziehen, die für das Senden und Empfangen der Netzwerkdaten auf niedriger Ebene verbraucht wird, wissen Sie, wie lange der Server für seine internen Berechnungen zur Verarbeitung der Anfrage benötigt hat .

Auch wenn Sie nicht sicher sind, wie viel Zeit im Netzwerk verbraucht wird, können Sie nach Variationen in den Roundtrip-Zeiten suchen, indem Sie viele Anfragen abschicken und jede Menge Proben sammeln.

Wenn das Netzwerk zuverlässig genug ist, um davon auszugehen, dass der Netzwerk-Overhead weitgehend konstant ist, können Sie mithilfe statistischer Methoden möglicherweise ableiten, welche Art von Datenänderung welche zusätzliche Verarbeitungsverzögerung verursacht.

Daraus können Sie möglicherweise etwas über die Struktur oder sogar den Inhalt der ursprünglichen unverschlüsselten Daten ableiten, die bei jeder wiederholten Anfrage geheim gehalten werden sollen.

Selbst wenn Sie nur ein Byte Klartext extrahieren können, nun, das sollte nicht passieren.

Sogenannt Timing-Angriffe dieser Art sind immer problematisch, selbst wenn Sie möglicherweise Millionen gefälschter Pakete senden und sie alle timen müssen, um eine Chance zu haben, auch nur ein Byte Klartextdaten wiederherzustellen …

…weil Netzwerke schneller, vorhersehbarer und in der Lage sind, viel mehr Last zu bewältigen als noch vor ein paar Jahren.

Man könnte meinen, dass Millionen von heimtückischen Paketen, die beispielsweise in der nächsten Stunde an Sie gesendet werden, wie ein freundlicher Daumen auffallen würden.

Aber „eine Million Pakete pro Stunde mehr oder weniger als üblich“ ist einfach keine besonders große Variante mehr.

Ähnlicher „Orakel“-Fehler in GnuTLS

Nun, die gleiche Person, die den endlich behobenen Fehler beim Timing in OpenSSL gemeldet hat, hat auch a ähnlicher Fehler in GnuTLS ungefähr zur gleichen Zeit.

Dieser hat die Fehlerkennung CVE-2023-0361.

Obwohl GnuTLS nicht ganz so beliebt oder weit verbreitet ist wie OpenSSL, haben Sie wahrscheinlich eine Reihe von Programmen in Ihrem IT-Bestand oder sogar auf Ihrem eigenen Computer, die es verwenden oder enthalten, möglicherweise einschließlich FFmpeg, GnuPG, Mplayer, QEMU , Rdesktop, Samba, Wget und Wireshark.

Ironischerweise tauchte der Timing-Fehler in GnuTLS in Code auf, der eigentlich Timing-Angriffsfehler protokollieren sollte.

Wie Sie dem Codeunterschied entnehmen können (diff) unten war dem Programmierer bewusst, dass jede bedingte (if ... then)-Operation, die beim Überprüfen und Behandeln eines Entschlüsselungsfehlers verwendet wird, kann zu Zeitabweichungen führen, da CPUs im Allgemeinen unterschiedlich viel Zeit benötigen, je nachdem, in welche Richtung Ihr Code nach einer „Verzweigungs“-Anweisung geht.

(Das gilt insbesondere für einen Zweig, der oft in die eine und selten in die andere Richtung geht, da CPUs dazu neigen, Code, der wiederholt ausgeführt wird, zu speichern oder zwischenzuspeichern, um die Leistung zu verbessern, wodurch die Ausführung selten ausgeführten Codes spürbar langsamer wird.)

Aber der Programmierer wollte trotzdem protokollieren, dass ein Angriff stattfinden könnte, was passiert, wenn die if (ok) Der obige Test schlägt fehl und verzweigt in den else { ... } .

An diesem Punkt ruft der Code auf _gnutls_debug_log() Funktion, die eine ganze Weile dauern kann, um ihre Arbeit zu erledigen.

Daher hat der Programmierer einen bewussten Aufruf von eingefügt _gnutls_no_log() der then { ... } Teil des Codes, der vorgibt, einen „Angriff“ zu protokollieren, obwohl keiner vorhanden ist, um zu versuchen, die Zeit auszugleichen, die der Code in beide Richtungen verbringt if (ok) Verzweigungsunterricht nehmen kann.

Anscheinend waren sich die beiden Codepfade jedoch in der Zeit, die sie verbrauchten (oder vielleicht auch nicht), nicht ausreichend ähnlich _gnutls_debug_log() Die Funktion allein war bei der Behandlung verschiedener Arten von Fehlern nicht ausreichend konsistent) und ein Angreifer konnte nach etwa einer Million Versuchen beginnen, Entschlüsselungsverräter zu unterscheiden.

Was ist zu tun?

Wenn Sie ein Programmierer sind: Die Fehlerbehebung hier war einfach und folgte dem „Weniger ist mehr“-Prinzip.

Der obige Code in Rosa, der sowieso keine besonders nützlichen Angriffserkennungsdaten liefern sollte, wurde einfach gelöscht, mit der Begründung, dass Code, der nicht vorhanden ist, nicht versehentlich einkompiliert werden kann, unabhängig von Ihren Build-Einstellungen …

… und Code, der nicht einkompiliert ist, kann niemals ausgeführt werden, weder aus Versehen noch aus Absicht.

Wenn Sie ein GnuTLS-Benutzer sind: die kürzlich veröffentlichte Version 3.7.9 und der „neue Produktgeschmack“ 3.8.0 haben diesen Fix, zusammen mit verschiedenen anderen, enthalten.

Wenn Sie eine Linux-Distribution ausführen, suchen Sie nach Updates für alle zentral verwalteten gemeinsam genutzten Bibliotheksversionen von GnuTLS, die Sie haben, sowie nach Apps, die ihre eigene Version mitbringen.

Suchen Sie unter Linux nach Dateien mit dem Namen libgnutls*.so herumliegende gemeinsam genutzte Bibliotheken zu finden und zu suchen gnutls-cli um alle Kopien des Befehlszeilenprogramms zu finden, die häufig in der Bibliothek enthalten sind.

Du kannst rennen gnutls-cli -vv um herauszufinden, welche Version von libgnutls es ist dynamisch verknüpft mit:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- meine Linux-Distribution hat das Update letzten Freitag (2023-02-10) bekommen

---

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/