Das OpenSSL-Projekt kündigte an, Version 3.0.7 am 1. November zu veröffentlichen, um eine kritische Sicherheitslücke zu schließen, die Version 3.0 und höher betrifft. Mitgründer Mark J. Cox merkte an: Es handelt sich erst um den zweiten kritischen Patch „seit wir 2014 begonnen haben, Sicherheitslücken zu bewerten“.
OpenSSL bezeichnetkritische Probleme als solche, die gängige Konfigurationen betreffen und wahrscheinlich ausnutzbar sind. Dazu zählen beispielsweise „die weitreichende Offenlegung von Inhalten des Serverspeichers (wodurch möglicherweise Benutzerdaten preisgegeben werden), Sicherheitslücken, die sich leicht aus der Ferne ausnutzen lassen, um private Serverschlüssel zu kompromittieren, oder Fälle, in denen die Ausführung von Code aus der Ferne unter gängigen Bedingungen als wahrscheinlich gilt“.
Der leitende Sicherheitslückenanalyst von ANALYGENCE, Art Manion, stellte fest, dass der 1. November, Allerheiligen, leider in mehreren EU-Ländern ein gesetzlicher Feiertag ist, und Cox räumte ein: „Das war uns nicht bewusst. Es ist ziemlich schwierig, jeden Feiertag überall zu vermeiden.“
Siehe die besten Tools für Code-Debugging und Codesicherheit
Was jetzt mit OpenSSL zu tun ist
Der Softwareentwickler Carlos Solís fragte: „Welche vorübergehenden Maßnahmen sollten also auf unseren Servern ergriffen werden, während die Sperrfrist aufgehoben wird?“ Cox antwortete unverblümt: „Wir haben zu diesem Zeitpunkt keine weiteren Informationen bereitgestellt.“
Dennoch schlugen Sophos-Forscher einen entscheidenden Schritt vor, der vor dem kommenden Dienstag ergriffen werden sollte, und rieten: „Alle OpenSSL-Nutzer sollten diese Zeit nutzen, um die OpenSSL-Instanzen zu erfassen und sich auf das sofortige Patchen vorzubereiten, sobald dieses veröffentlicht wird.“
Cox stimmte zu: „Das ist ein guter Rat. Wenn Sie im Voraus wissen, wo Sie OpenSSL 3.0+ einsetzen und wie Sie es verwenden, können Sie bei Veröffentlichung des Hinweises schnell feststellen, ob und wie Sie betroffen sind und was Sie patchen müssen.“
Um diesen Prozess zu unterstützen, hat der Forschungsdekan des SANS-Instituts, Johannes B. Ullrich, eine Liste veröffentlicht: Sie enthält die OpenSSL-Versionen für mehr als 25 Betriebssysteme. Dazu merkt er an: „MacOS verwendet standardmäßig LibreSSL und nicht das installierte openssl. openssl kann jedoch später von anderer Software wie Homebrew und MacPorts installiert werden.“
Lesen Sie auch: Sind Patch-Management-as-a-Service die Antwort auf Sicherheitslücken?
Das nächste Heartbleed?
Mattias Gees, Produktleiter für Container bei Venafi, sagte, die Ankündigung erinnere an äußerst folgenreiche Sicherheitslücken wie Heartbleed und Log4Shell. „Heartbleed hatte erhebliche Auswirkungen auf die Betriebsteams weltweit, und seitdem ist die IT-Infrastruktur zehnmal komplexer geworden“, sagte er.
„Als Heartbleed entdeckt wurde, nutzte die Mehrheit der IT-Organisationen dedizierte Hardware oder virtuelle Maschinen (VMs)“, sagte Gees. „Doch inzwischen befinden wir uns im Cloud-Native-Zeitalter. Es hat fortschrittliche Container und serverloseArchitekturen hervorgebracht. Der Angriffsvektor ist deutlich größer geworden. Organisationen müssen nun, statt nur ihre VMs zu untersuchen, damit beginnen, als Reaktion auf diese Ankündigung das Patchen all ihrer Container-Images vorzubereiten.“
Organisationen, die als Reaktion auf Log4Shell bereits ihre Abhängigkeiten geprüft haben, so Gees, sind bestens aufgestellt, um eine Lösung so effizient wie möglich bereitzustellen.
Die Tatsache, dass die Sicherheitslücke nur Version 3.0 und höher betrifft, sollte zumindest ihre potenziellen Auswirkungen begrenzen, fügte er hinzu. „Doch Plattform-Engineering-Teams sollten weiterhin in eine bessere Prüfung ihrer Umgebungen und Abhängigkeiten investieren, denn die nächste Bedrohung kommt bestimmt – und steht immer kurz bevor.“
Als Nächstes lesen: