OpenSSL-Patches sind da – KRITISCHER Fehler auf HOCH heruntergestuft, aber trotzdem patchen!

Wir beginnen mit den wichtigen Dingen: den lange erwarteten OpenSSL-Bugfixes, die letzte Woche angekündigt wurden sind aus.

OpenSSL 1.1.1 geht zu Version 1.1.1s, und behebt einen aufgelisteten sicherheitsrelevanten Fehler, aber dieser Fehler hat keine Sicherheitsbewertung oder eine offizielle CVE-Nummer.

Wir empfehlen dringend, dass Sie aktualisieren, aber das KRITISCHE Update, das Sie in den Cybersicherheitsmedien gesehen haben, gilt nicht für diese Version.

OpenSSL 3.0 geht zu Version 3.0.7, und patcht nicht einen, sondern zwei CVE-nummerierte Sicherheitsfehler, die offiziell mit HOHER Schweregrad gekennzeichnet sind.

Wir empfehlen dringend, dass Sie mit so viel Dringlichkeit wie möglich aktualisieren, aber der KRITISCHE Fix, über den alle gesprochen haben, wurde jetzt auf den Schweregrad HOCH herabgestuft.

Dies spiegelt die Meinung des OpenSSL-Teams wider:

Vorankündigungen von CVE-2022-3602 beschrieb dieses Problem als KRITISCH. Weitere Analysen auf der Grundlage einiger der [in den Versionshinweisen] beschriebenen mildernden Faktoren haben dazu geführt, dass dies auf HOCH herabgestuft wurde. Benutzer werden weiterhin aufgefordert, so schnell wie möglich auf eine neue Version zu aktualisieren.

Ironischerweise wird ein zweiter und ähnlicher Fehler synchronisiert CVE-2022-3786, wurde entdeckt, während der Fix für CVE-2022-3602 vorbereitet wurde.

Der ursprüngliche Fehler erlaubt einem Angreifer nur, vier Bytes auf dem Stack zu korrumpieren, was die Ausnutzbarkeit der Lücke einschränkt, während der zweite Fehler eine unbegrenzte Menge an Stapelüberlauf zulässt, aber anscheinend nur das „Punkt“-Zeichen (ASCII 46 oder 0x2E ) immer wieder wiederholt.

Beide Schwachstellen werden während der TLS-Zertifikatsüberprüfung offengelegt, bei der sich ein mit Sprengfallen versehener Client oder Server gegenüber dem Server oder Client am anderen Ende mit einem absichtlich falsch formatierten TLS-Zertifikat „identifiziert“.

Obwohl diese Art von Stapelüberlauf (einer mit begrenzter Größe und der andere mit begrenzten Datenwerten) so klingt, als wären sie für die Codeausführung schwer auszunutzen (insbesondere in 64-Bit-Software, wo vier Bytes nur die Hälfte einer Speicheradresse sind) …

… sie sind mit ziemlicher Sicherheit leicht für DoS-Angriffe (Denial of Service) ausnutzbar, bei denen der Absender eines Rogue-Zertifikats den Empfänger dieses Zertifikats nach Belieben zum Absturz bringen könnte.

Glücklicherweise beinhalten die meisten TLS-Austausche Clients, die Serverzertifikate überprüfen, und nicht umgekehrt.

Die meisten Webserver verlangen zum Beispiel nicht, dass Besucher sich mit einem Zertifikat identifizieren, bevor sie ihnen erlauben, die Seite zu lesen, so dass die „Absturzrichtung“ aller funktionierenden Exploits wahrscheinlich darin besteht, dass bösartige Server unglückliche Besucher zum Absturz bringen, was allgemein angenommen wird viel weniger schwerwiegend als Server, die jedes Mal abstürzen, wenn sie von einem einzelnen böswilligen Besucher aufgerufen werden.

Dennoch muss jede Technik, mit der ein gehackter Web- oder E-Mail-Server einen besuchenden Browser oder eine E-Mail-App grundlos zum Absturz bringen kann, als gefährlich angesehen werden, nicht zuletzt, weil jeder Versuch der Client-Software, die Verbindung erneut zu versuchen, dazu führt, dass die App immer und immer wieder abstürzt wieder.

Sie wollen also unbedingt Patch dagegen so schnell wie möglich.

Was ist zu tun?

Wie oben erwähnt, brauchst du OpenSSL 1.1.1s or OpenSSL 3.0.7 um die Version zu ersetzen, die Sie im Moment haben.

OpenSSL 1.1.1s erhält einen Sicherheitspatch, der als Fixing bezeichnet wird „eine Regression [ein alter Fehler, der wieder auftauchte], der in OpenSSL 1.1.1r eingeführt wurde und die zu signierenden Zertifikatsdaten nicht aktualisiert, bevor das Zertifikat signiert wird“, diesem Fehler ist kein Schweregrad oder CVE zugewiesen …

…aber lassen Sie sich dadurch nicht davon abhalten, so schnell wie möglich zu aktualisieren.

OpenSSL 3.0.7 erhält die beiden oben aufgeführten CVE-nummerierten HOHE-Schwere-Korrekturen, und obwohl sie jetzt nicht mehr ganz so beängstigend klingen wie in den Nachrichten vor dieser Veröffentlichung, sollten Sie davon ausgehen, dass:

• Viele Angreifer werden schnell herausfinden, wie sie diese Lücke für DoS-Zwecke ausnutzen können. Dies kann bestenfalls zu Unterbrechungen des Arbeitsablaufs und schlimmstenfalls zu Problemen mit der Cybersicherheit führen, insbesondere wenn der Fehler missbraucht werden kann, um wichtige automatisierte Prozesse (z. B. Updates) in Ihrem IT-Ökosystem zu verlangsamen oder zu unterbrechen.
• Einige Angreifer können diese Fehler möglicherweise für die Ausführung von Remotecode ausnutzen. Dies würde Kriminellen eine gute Chance geben, mit Sprengfallen versehene Webserver zu verwenden, um Client-Software zu untergraben, die für sichere Downloads in Ihrem eigenen Unternehmen verwendet wird.
• Wenn ein Proof-of-Concept (PoC) gefunden wird, wird er auf großes Interesse stoßen. Wie Sie sich von Log4Shell erinnern werden, sprangen, sobald PoCs veröffentlicht wurden, Tausende von selbsternannten „Forschern“ auf den Zug „Das Internet scannen und angreifen, während Sie gehen“ unter dem Deckmantel auf, den Menschen beim Finden zu „helfen“. Probleme in ihren Netzwerken.

Beachten Sie, dass OpenSSL 1.0.2 weiterhin unterstützt und aktualisiert wird, jedoch nur privat, für Kunden, die Verträge mit dem OpenSSL-Team bezahlt haben, weshalb wir hier keine Informationen darüber offenlegen können, außer um zu bestätigen, dass die CVE -nummerierte Fehler in OpenSSL 3.0 gelten nicht für die OpenSSL 1.0.2-Reihe.

Du kannst dich mehr dazu, und holen Sie sich Ihre OpenSSL-Updates, Aus der OpenSSL-Website.

Oh, und wenn PoCs online auftauchen, seien Sie bitte kein Clever-Clogs und fangen Sie an, diese PoCs an den Computern anderer Leute „auszuprobieren“, unter dem Eindruck, dass Sie bei irgendeiner Art von „Forschung“ „helfen“.

---