Ich weiß nicht, wer es von euch mitgekriegt hat: im SSL – also dem “Secure Socket Layer”, das hat mit diesem “https” zu tun, das an jeder Adresse dransteht – ist eine Sicherheitslücke. Ein sogenannter 0day, oder auch Zero-Day-Exploit. Das sind Lücken, die dem, der das eigentlich wissen sollte, noch nicht aufgefallen waren.
Die Schwere der Lücke wird als “kritisch” eingestuft, das ist die höchste Stufe. Betrifft “gängige Konfigurationen” und kann “wahrscheinlich ausgenutzt werden.” Der Fehler kann dem Angreifer Zugang zu Benutzerdaten, das Ausspähen der privaten Schlüssel des Servers oder Ausführen von Fremdcode ermöglichen.
Das OpenSSL-Team hat bisher logischerweise nicht damit rausgerückt, wo die Lücke ist, aber am 1.11. nachmittags wird der Bugfix “ausgerollt” (Version 3.0.7.). Alle (!) Admins (zumindest die, die sich zu Recht so schimpfen) sitzen jetzt in den Startlöchern und werden den Fix ASAP (as soon as possible) einspielen. Da Open SSL nicht nur in Servern, sondern auch in PHP-Installationen steckt, dürfte es Dienstag nachmittag – zwischen 13:00 und 17:00 UTC – im Internet “etwas” knirschen. Auch die Olypedia und natürlich alle meine Webpräsenzen inklusive Shop sind betroffen.
Wir sehen uns nach dem Bugfix wieder.
Hoffe ich.
Der betreffende kritische Fehler liegt laut den OpenSSL-Entwicklern nur in OpenSSL-Versionen ab 3.0 vor. Da es außer OpenSSL noch andere TLS-Implementierungen gibt und die Verbreitung von OpenSSL 3.0.x (im Vergleich zu früheren Versionen) aktuell auch noch ziemlich überschaubar ist – laut webtechsurvey.com zum Beispiel benutzen weniger als 1% der erfassten 1.5 Millionen Server auf dem Internet OpenSSL 3.x –, ist das Ganze vermutlich erst mal halb so wild und das Internet insgesamt nicht wirklich in Gefahr. Meine Server sind zum Beispiel nicht betroffen.
Server-Admins mit OpenSSL 3.0.x (z.B. auf Ubuntu 22.04 oder Red Hat Enterprise Linux 9) sollten allerdings in der Tat zeitnah upgraden, just in case – auch wenn noch niemand außer ein paar Eingeweihten weiß, wie genau der Fehler sich auswirkt. OpenSSL ist eine sehr umfangreiche Software und die wenigsten Leute benutzen tatsächlich alles, was OpenSSL kann.
Ein “Zero-Day-Exploit” ist übrigens keine Sicherheitslücke an sich, sondern ein Schadcode, der eine Sicherheitslücke ausnutzt, die dem Hersteller der Software (noch) nicht bekannt ist, d.h., der Hersteller hat bei Bekanntwerden der Sicherheitslücke “null Tage” Zeit, um einen Patch zur Verfügung zu stellen. Dies im Gegensatz zu sog. “responsible disclosure”-Ansätzen, wo der Entdecker einer Sicherheitslücke den Hersteller im Vertrauen darauf aufmerksam macht und ihm z.B. 30 Tage Zeit gibt, einen Patch zu liefern, bevor beispielhafter Code veröffentlicht wird, der die Sicherheitslücke demonstriert. Zero-Day-Exploits werden gerne von Cyberkriminellen oder Geheimdiensten gekauft, weil sie sich damit idealerweise unbemerkten Zugang zu fremden Systemen verschaffen können; ein Zero-Day-Exploit wird wertlos (oder zumindest weitaus weniger wert), sobald das betreffende Problem vom Hersteller repariert wird, und darum profitieren die Käufer davon, die unterliegenden Sicherheitslücken möglichst geheim zu halten. Ob es für das vorliegende Problem in OpenSSL 3.x einen Zero-Day-Exploit gibt, wissen wir nicht.
Herzlichen Dank für die ausführliche Erklärung. Ich gebe zu, ich habe unzulässig vereinfacht. 😉
Nur zur Info noch, weil das oben missverständlich rübergekommen ist: Ich werde selbst die Patches nicht einspielen, weil sowohl bei Strato als auch bei Gambio, meinem Shop-Hoster, die dortigen Admins dafür zuständig sind.
Allerdings: Dass die Sache so harmlos ist – 1% – würde ich jetzt nicht unterschreiben. Strato und Hetzner verwenden OpenSSL, natürlich in der aktuellen, betroffenen Version. Und die beiden haben schon einen ziemlichen Kuchen des deutschen Hostings. (Allerdings nehme ich auch an, dass die es “drauf” haben, das Zeug schnell und transparent einzuspielen.)
Ich denke auch, wer “managed hosting” bei namhaften Firmen wie Strato oder Hetzner verwendet, kann sich auf die dortigen Admins verlassen, dass die aktuelle OpenSSL-Version eingespielt wird.
Wobei die “aktuelle Version” bei OpenSSL die 3.0.x sein kann (das ist die neueste), aber auch die bisherige “Long Term Support”-Version 1.1.1 wird noch offiziell gewartet bis September 2023. Am 1.11. kommt auch dafür eine Bugfix-Version heraus, die aber andere (nicht kritische) Sachen repariert, denn das kritische Problem ist ja nur in der 3.x vorhanden.
Es ist also jedenfalls im Moment in keiner Weise ehrenrührig, seinen Server noch mit der ebenfalls “aktuellen” 1.1.1-Version von OpenSSL laufen zu lassen, und genau das tut bisher auch die weit überwiegende Mehrheit – etwa alle Leute, die (wie ich) selbstverwaltete Cloud-Server auf der Basis von Debian GNU/Linux 11 (“Bullseye”) benutzen (oder diverse andere gängige und gewartete Linux-Distributionen wie RHEL 8, Ubuntu 20.04 LTS, …). Bei Debian wird der Schritt auf OpenSSL 3.x mit der Version 12 (“Bookworm”) erfolgen, die mit großer Sicherheit noch deutlich vor dem nächsten September erscheinen wird, es gibt also keinen Grund zur Besorgnis.
Jetzt wissen wir auch, was die “kritische” Sicherheitslücke ist: Zwei “Buffer Overflows” in der Punycode-Dekodierung von E-Mail-Adressen in X.509-Zertifikaten wurden repariert. Einer davon (CVE-2022-3602) war als Problem gemeldet worden und der zweite (CVE-2022-3786) wurde bei der Analyse des ersten gefunden.
Punycode ist eine Methode, mit der man im DNS – der Datenbank, die (unter anderem) Servernamen auf IP-Adressen oder die Teile nach dem “@” in E-Mail-Adressen auf Mailserver-Namen abbildet – Namen definieren kann, die Nicht-ASCII-Zeichen enthalten. Eigentlich erlaubt sind nämlich nur die 26 üblichen Buchstaben und 10 Ziffern des ASCII, “-” und “_”. Die Details sind unappetitlich, aber der Domainname “äöüß.de” würde zum Beispiel als “xn--ss-uia6e4a.de” im DNS eingetragen, von den gängigen Browsern aber als “äöüß.de” dargestellt.
In OpenSSL 3.x vor 3.0.7 ist es möglich, X.509-Zertifikate zu konstruieren, die eine E-Mail-Adresse mit einer Punycode-codierten Domain enthalten, die bei der Dekodierung einen Buffer Overflow auslöst. Dies kann zum Programmabsturz führen (“Denial of Service”) oder potenziell die Ausführung von beliebigem Code erlauben.
Anfällig sind TLS-Clients, wenn sie sich mit einem Server verbinden, der so ein Zertifikat benutzt, oder TLS-Server, wenn sie von Clients Zertifikate zur Authentifizierung anfordern und so ein Zertifikat geschickt bekommen. In jedem Fall wird der betroffene Code erst ausgeführt, nachdem die Gültigkeit des Zertifikats geprüft wurde, und setzt entweder voraus, dass eine Zertifizierungsstelle das bösartige Zertifikat beglaubigt hat oder dass das betreffende Programm das bösartige Zertifikat nach einer fehlgeschlagenen Gültigkeitsprüfung nicht verwirft.
Wir können also aufatmen, weil der Kreis der tatsächlich betroffenen Server auf dem Internet extrem klein sein dürfte. Die Schwere des Problems wurde auch von “kritisch” auf “hoch” heruntergestuft. Leute, die anfällige Versionen von OpenSSL verwenden, sollten trotzdem baldmöglichst upgraden.