Im Verlauf der vergangenen Woche wurden die Andeutungen nicht nur immer deutlicher, sie ließen auch Schlimmes befürchten. In Kürze sollten neue kritische Lücken in OpenSSL öffentlich gemacht werden – und damit einer Bibliothek, die im Internet eine wichtige Rolle zur Verschlüsselung – und damit auch zur Absicherung – von Daten einnimmt. Findet sich OpenSSL doch in einer riesigen Zahl an Produkten – von Linux-Distributionen bis zu Routern und anderen Systemen, die eine zentrale Rolle in der Internetinfrastruktur einnehmen.

Böse Erinnerungen

Die Vorankündigung rief dabei auch einen Vorfall in Erinnerung, dessen Namen alleine schon manchen einen kalten Schauer über den Rücken jagen dürfte. Mit "Heartbleed" sorgte vor acht Jahren eine Reihe von kritischen Lücken in OpenSSL für ein veritables Chaos im Netz. Systemadministratoren mussten ihre Systeme in Windeseile fixen – aber oft auch erst einmal herausfinden, wo OpenSSL überhaupt alles sonst noch so genutzt wird, ohne dass man es wirklich weiß. Die Auswirkungen von Heartbleed sollten die Computerwelt in der Folge lange beschäftigen.

Angesichts dessen geht mit der offiziellen Enthüllung der neuen Lücken nun schon fast Erleichterung einher. Denn wie sich mit einem Blick auf die Details zeigt, handelt es sich dabei beileibe nicht um ein "Heartbleed 2", wie manche im Vorfeld befürchtet haben. So hat das OpenSSL-Projekt den Schweregrad der beiden Lücken mittlerweile herabgestuft – und zwar von "kritisch" auf "hoch". Doch auch sonst scheint die IT-Welt dieses Mal viel besser aufgestellt zu sein.

Reaktion

Dank der Vorankündigung bieten viele betroffene Systeme bereits Updates auf fehlerbereinigte Versionen an. Vor allem aber sind die Lücken auf die neueste OpenSSL-Generation beschränkt – und diese wird von vielen noch gar nicht eingesetzt. Betroffen sind also nur Systeme mit OpenSSL 3.x, geschlossen werden die Fehler mit der neuen Version 3.0.7. Wer hingegen noch die älteren – und noch aktiv gewarteten – Versionen 1.1.x oder 1.0.x einsetzt, muss also gar nichts tun.

Bei beiden Lücken geht es um eine Schwäche in der Verarbeitung von Zertifikaten. Über spezielle E-Mail-Adressen kann im Parser für X509-Zertifikate eine Pufferüberlauf provoziert werden, in dessen Folge dann Schadcode eingeschmuggelt werden kann. Klingt schlimm, in der Praxis stehen einer solchen Attacke aber einige Hindernisse im Weg.

Viele Einschränkungen

Da wäre zunächst, dass ein solches Zertifikat in den meisten Fällen eine Echtheitsprüfung überstehen muss, ein Angreifer müsste also eine offizielle Zertifikatsstelle finden, die so etwas ausstellt. Zwar gibt es auch OpenSSL-Konfigurationen, wo unüberprüft Zertifikate übernommen werden. Wie weit verbreitet diese sind, ist derzeit aber noch nicht klar.

Vor allem aber dürften von der Lücke vor allem Client-Systeme, aber kaum Server betroffen sein. Das liegt daran, dass für einen solchen Angriff überhaupt einmal die zertifikatsbasierte Client-Authentifizierung aktiviert sein muss, was bei Servern wenig verbreitet ist.

Zudem würden bei vielen Systemen – etwa den meisten Linux-Distributionen – andere Sicherheitsmaßnahmen die Ausführung von Schadcode nach einem solchen Angriff effektiv verhindern, wie der Sicherheitsforscher Kevin Beaumont herausstreicht. Bei Akamai hatte man schon vor einigen Tagen Tipps zur Absicherung gegeben – damals noch ohne konkrete Details zu den eigentlichen Lücken zu nennen. Auch darüber dürften sich manche Systemadministratoren bereits vorbereitet haben.

Update!

Entsprechende Updates stehen wie gesagt bereits für viele Systeme zum Download bereit. Eine ausführliche Liste betroffener – aber auch nicht betroffener – Betriebssysteme pflegt das niederländische Nationaal Cyber Security Centrum (NCSC-NL) auf Github. Auch wenn die Lücken jetzt nicht mehr als "kritisch" gelten, so bleibt doch der Ratschlag, entsprechende Updates so schnell wie möglich einzuspielen. (Andreas Proschofsky, 2.11.2022)