Wenn Sie ein OpenSSL-Benutzer sind, kennen Sie wahrscheinlich die neuesten hochkarätiger Bugfix Veröffentlichung, die im März 2022 herauskam.

Dieser Fix brachte uns OpenSSS 3.0.2 und 1.1.1n, Updates für die beiden derzeit vollständig unterstützten Varianten des Produkts.

(Es gibt eine Legacy-Version, 1.0.2, aber Updates für diese Version sind nur für Kunden verfügbar, die für Premium-Support bezahlen, und angesichts der Änderungen und Verbesserungen am Produkt seit den Tagen von 1.0.2 bitten wir Sie dringend, zu a Mainstream-Version sogar – vielleicht besonders – wenn Sie vorhaben, weiterhin für den Support zu bezahlen.)

Das Update vom März 2022 war eine wichtige Erinnerung daran, dass tief vergrabener Code mit ungewöhnlichen Fehlern jahrelang übersehen werden kann, insbesondere wenn dieser Code Teil einer komplexen, spezialisierten Low-Level-Funktion ist.

Der damals behobene Fehler bezog sich auf einen Spezialalgorithmus zur Berechnung sogenannter modulare Quadratwurzeln, die komplizierter zu berechnen sind als normale Quadratwurzeln.

Leider war der Code zur Durchführung dieser Berechnung unter Verwendung eines Algorithmus, der erstmals in den 1890er Jahren entdeckt wurde, ungeschickt codiert, verschlungen geschrieben, schlecht kommentiert und schwer zu befolgen.

Da es sich jedoch nicht in einem offensichtlich „nach außen gerichteten“ Teil von OpenSSL befand und es eine entmutigende Aufgabe gewesen wäre, es neu zu schreiben, gehen wir davon aus, dass es sorgfältig auf die Korrektheit seiner Antworten getestet wurde, wenn es präsentiert wurde Wohlgeformte Zahlen, aber nicht auf ihre Robustheit geprüft, wenn sie mit unwahrscheinlichen Eingaben konfrontiert werden.

Denn wenn man mit digitalen Zertifikaten konfrontiert wird, die mit einer Sprengfalle versehen wurden, um falsch geformte Zahlen zu produzieren, OpenSSL's BN_mod_sqrt() Funktion könnte dazu verleitet werden, sich für immer zu wiederholen und zu versuchen, sich einer Antwort zu nähern, die nicht existiert.

Wenn Sie nur mit ganzen Zahlen arbeiten und Brüche jeglicher Art verbieten, stellen Sie fest, dass viele Zahlen keine modularen Quadratwurzeln haben, genauso wie Sie feststellen, dass viele ganze Zahlen keine regulären Quadratwurzeln haben. Also ist 7×7 = 49, also hat 49 eine Quadratwurzel, die eine ganze Zahl ist, nämlich 7. Aber es gibt keine ganze Zahl, die mit sich selbst multipliziert werden kann, um 50 oder 51 zu ergeben, weil das nächste „perfekte Quadrat“ 8×8 ist = 64. Sie können es so lange versuchen, wie Sie möchten, aber Sie werden nie eine ganzzahlige Antwort für √51 finden.

Nie wirklich falsch, nur unvollständig

Mit anderen Worten, obwohl der BigNumber-Code von OpenSSL (viele Verschlüsselungsalgorithmen verlassen sich darauf, mit Zahlen zu arbeiten, die Hunderte oder sogar Tausende von Ziffern lang sind) nie eine Wrongs antworten, merkte es manchmal nicht, dass es keine Antwort zu finden gab, und blieb in einer Endlosschleife stecken.

Diese Endlosschleife, die missbraucht werden könnte, um etwas zu provozieren, das als a Denial of Service Angriff (DoS), könnte ausgelöst werden, wenn eine böswillige Website über ein mit Sprengfallen versehenes digitales Zertifikat gesendet wird.

Dies bedeutete ironischerweise, dass Software, die bei der Validierung digitaler Zertifikate gewissenhaft war, durch diesen Fehler, der als CVE-2022-0778, während Programme, die sich überhaupt nicht um die Zertifikatsvalidierung kümmerten, davon nicht betroffen waren.

Angesichts der wichtigen „lehrbaren Momente“, die durch diesen Fehler aufgedeckt wurden, haben wir ihn nicht nur auf Naked Security ausführlich behandelt, wo wir ihn erklärt haben wie man einen besseren Codestil schreibt, sondern auch auf Sophos News, wo die SophosLabs die blutigen Details darüber zeigten, wie ein mit Sprengfallen versehenes Zertifikat den Fehler auslösen könnte, und wie man den Code debuggt, um den Fehler zu verstehen.

Inzwischen zwei weitere Sicherheitslücken

Das nächste OpenSSL-Update war 3.0.3, oder 1.1.1o für Benutzer der vorherigen Version, die einen Fehler behoben hat, der nicht als schwerwiegender Fehler angesehen wurde (zumindest haben wir ihn nicht auf Naked Security behandelt), hauptsächlich weil der Fehler nicht im Code der OpenSSL-Verschlüsselungsbibliothek selbst enthalten war.

Anstatt die gesamte Software zu beeinträchtigen, die sich auf OpenSSL als kryptografischen Anbieter stützte, CVE-2022-1292 betraf gerade ein in Perl geschriebenes Hilfsskript, das mit dem OpenSSL-Toolkit geliefert wurde.

Dieses Skript, bekannt als c_rehash (kurz für Zertifikatsverzeichnis neu aufbereiten) ist ein wenig bekanntes Tool, das ein Verzeichnis kryptografischer Zertifikatsdateien verwendet, wie sie beispielsweise von Mozilla als vertrauenswürdige Zertifizierungsstellen (CAs) verwaltet werden, und eine Liste von Datei-Hashes erstellt, die der Software helfen können, bestimmte Zertifikate schneller zu finden, als sie zu durchsuchen alphabetisches Namensverzeichnis.

Das CA-Zertifikatsverzeichnis von Mozilla sieht beispielsweise so aus …

$ ls -l /usr/share/ca-certificates/mozilla -rw-r--r-- 1 duck duck 2772 2022-06-23 05:32 ACCVRAIZ1.crt -rw-r--r-- 1 duck duck 1972 2022-06-23 05:32 AC_RAIZ_FNMT-RCM.crt -rw-r--r-- 1 Ente Ente 904 2022-06-23 05:32 AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt [. . .] -rw-r--r-- 1 duck duck 1302 2022-06-23 05:32 emSign_Root_CA_-_G1.crt -rw-r--r-- 1 duck duck 774 2022-06-23 05:32 vTrus_ECC_Root_CA .crt -rw-r--r-- 1 duck duck 1911 2022-06-23 05:32 vTrus_Root_CA.crt

…während OpenSSL ist c_rehash Das Skript generiert eine Liste symbolischer Links, die es ermöglichen, einzelne Zertifikate über Hashes basierend auf dem Namen des Ausstellers im Zertifikat selbst und nicht über seinen Dateinamen zu finden:

LRWXRWXRWX 1 Duck Duck 23 2022-06-24 13:41 002C0B4F.0-> Globalsign_root_R46.CRT LRWXRWXRWX 1 Duck Duck 45 2022-06-24 13:41 02265526.0-> Entrust_RUST_CERT_CERTIFATION_AUTHORITION _-_-_-_-_-_-_-_CRWX. -2 1:36 2022a06 -> Staat_der_Nederlanden_EV_Root_CA.crt [. . .] lrwxrwxrwx 24 Ente Ente 13 41-03179-64.0 1:19 fe2022a06cd24 -> SZAFIR_ROOT_CA13.crt lrwxrwxrwx 41 Ente Ente 8 2-8.0-2 1:23 feffd2022 -> GlobalSign_Root_E06.crt lrwxrwxrwx 24 Ente13 Ente 41 -413.0-46 1:49 ff2022af06f.24 -> TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_13.crt

Manche Software nutzt diese „Hash-Links“, um als eine Art grundlegendes Datenbanksystem zum Indexieren und Auffinden bestimmter Zertifikate zu fungieren.

Darüber hinaus rufen einige Betriebssystem-Distributionen automatisch die c_rehash Skript im Hintergrund, um diese speziellen Links auf dem neuesten Stand zu halten.

Shell-Metazeichen gelten als schädlich

Leider stützte sich das Skript auf Perl system() Funktion (oder ein gleichwertiger Befehl) zum Berechnen der Datei-Hashes und der system() Das System startet automatisch eine Befehlsshell wie Bash, um alle erforderlichen Unterprogramme zu starten.

Und wie Sie wahrscheinlich wissen, behandeln Befehlsshells ihre Befehlszeilenargumente nicht immer wörtlich, sodass die Shell, wenn Sie Sonderzeichen in diese Argumente einfügen, diese auf potenziell gefährliche Weise behandelt.

Zum Beispiel der Befehl echo runthis druckt buchstäblich den Text runthis, aber der Befehl echo $(runthis) druckt die Zeichen nicht direkt aus $(runthis).

Stattdessen die sog Metabefehl $(runthis) Mittel Befehlsersetzung, also heißt es: „Führen Sie den Befehl aus runthis und ersetzen Sie die $(...) Teil mit der Ausgabe dieses Befehls, wenn er fertig ist“:

   # wörtlich behandeltes Argument, keine Metazeichen gefunden $ echo runthis runthis # versucht, 'runthis' auszuführen, aber kein solcher Befehl existiert $ echo $(runthis) -bash: runthis: command not found # führt zwei Befehle aus, sammelt die Ausgabe von beiden $ echo $(whoami; uname -s -r) Ente Linux 5.18.6

Wenn das Risiko besteht, durch $(...) kommt Ihnen bekannt vor, das liegt daran, dass kürzlich die metacommand-Schwachstelle ausgenutzt wurde „Follina“-Fehler unter Windows. Um mehr zu erfahren und diesen Fehler live in Aktion zu sehen, können Sie sich unser aufgezeichnetes Webinar ansehen. Klicken Sie einfach auf das Bild unten. [Registrierung erforderlich, Zugang erfolgt danach sofort.]

Was wurde behoben?

Skripte, die nicht vertrauenswürdige Eingaben von jemand anderem akzeptieren – sei es eine Zeichenfolge, die in ein Webformular eingegeben wird, oder ein erfundener Dateiname, der von außen bereitgestellt wird – müssen sehr vorsichtig sein, damit diese speziellen Metabefehle nicht als Shell-Argumente durchsickern, wenn sie sich auf den Befehl verlassen Shell zum Ausführen externer Dienstprogramme.

Unten sehen Sie den geänderten Code 1.1.1n zu 1.1.1o:

Ein Perl-Befehl des Formulars `...` (ein Befehl zwischen Backticks, wie z `runthis`, ist einfach eine altmodische Schreibweise $(runthis) Befehlsersetzung) wurde durch eine dedizierte interne Funktion namens ersetzt compute_hash das kümmert sich besser um seltsame Metazeichen in der konstruierten Befehlszeichenfolge.

Nun, es stellt sich heraus, dass die Betreuer nicht alle Stellen in diesem Utility-Skript verstanden haben, an denen ein externer Befehl ohne gebührende Sorgfalt und Aufmerksamkeit ausgeführt wurde.

Diese Woche also sah die Veröffentlichung von OpenSSL 3.0.4 und 1.1.1p, um einen weiteren riskanten Systembefehl in der c_rehash Nützlichkeit:

Diesmal war es ein Aufruf an die cp (Datei kopieren) Befehl über die Shell-basierte system() Funktion, die durch eine sicherere, dedizierte interne Funktion namens ersetzt wurde copy_file.

Dieser Bugfix hat die offizielle Kennung CVE-2022-2068.

Wie das OpenSSL-Änderungsprotokoll warnt:

[The c_rehash]-Skript wird von einigen Betriebssystemen so verteilt, dass es automatisch ausgeführt wird. Auf solchen Betriebssystemen könnte ein Angreifer beliebige Befehle mit den Rechten des Skripts ausführen.

Was ist zu tun?

• Aktualisieren Sie OpenSSL so bald wie möglich. Wenn Sie sich auf Ihre Linux-Distribution verlassen, um eine zentral installierte Kopie zu verwalten, erkundigen Sie sich bei Ihrem Distributionshersteller nach Einzelheiten. Wenn Sie sich auf Ihren eigenen OpenSSL-Build statt (oder zusätzlich zu einem systemweiten) verlassen, vergessen Sie nicht, auch diese Kopie zu aktualisieren. Du schaust nach 3.0.4 or 1.1.1p. Lauf openssl version um zu sehen, welche Version du hast.
• Erwägen Sie, die in den Ruhestand zu versetzen c_rehash Dienstprogramm, wenn Sie es verwenden. Das All-in-One-Dienstprogramm openssl, das üblicherweise in erster Linie zum Generieren und Signieren von Zertifikaten verwendet wird, enthält jetzt einen integrierten Unterbefehl namens rehash um die gleiche Arbeit zu machen. Versuchen openssl rehash -help und fordern Sie weitere Informationen an.
• Bereinigen Sie Ihre Ein- und Ausgänge. Gehen Sie niemals davon aus, dass Sie erhaltene Eingaben sicher unverändert verwenden können, und seien Sie vorsichtig mit den Daten, die Sie als Ausgabe an andere Teile Ihres Codes weitergeben.
• Achten Sie auf mehrere Fehler, wenn Sie den Code auf bestimmte Arten von Fehlern überprüfen. Ein Programmierer, der unachtsam mit a umging system() Befehl an einer Stelle im Code kann ähnliche Fehler an anderer Stelle gemacht haben.

Programmierer produzieren (oder reproduzieren) oft viele Male die gleiche Art von Fehlern, normalerweise aus völlig harmlosen und verständlichen Gründen.

Entweder waren sie sich dieser Art von Fehlern nicht bewusst, als sie am Code arbeiteten, oder sie nahmen eine „vorübergehende Abkürzung“, um die Prototypenarbeit zu beschleunigen, gingen aber nie zurück und räumten später auf, oder sie kopierten und fügten jemanden ein anderer fehlerhafter Code und machte ihn zu seinem eigenen …