Software::Security
Sicherheitslücke in LZO: Weltuntergang vertagt
Eine potentielle Sicherheitslücke bei der Dekompression in den Algorithmen LZO und LZ4 bringt Bedenken auf, gerade ein zweites Heartbleed zu erleben. Doch anscheinend bedarf es unrealistisch langer Datenblöcke, um die Sicherheitslücke auszunutzen - viel Drama um nichts?
Mirko Lindner
Vor 19 Jahren erfand Markus Oberhumer den
LZO-Algorithmus, einen Kompressionsalgorithmus, der nicht so stark komprimiert wie das frühere LZW-Verfahren, aber alle anderen an Geschwindigkeit weit übertrifft. Insbesondere benötigt die Dekompression keinen zusätzlichen Speicher und erreicht immerhin ein Drittel der Geschwindigkeit einer reinen Kopier-Operation.
In den letzten Jahren entstand eine Variante von LZO unter dem Namen LZ4. Beide Algorithmen sind in breitem Einsatz überall dort, wo es auf schnelle Kompression und Dekompression mehr ankommt als auf den Kompressionsfaktor. So sind LZO und LZ4 in Dateisystemen (einschließlich ZFS), Mobilgeräten, Routern, im Kernel von Linux und zahlreichen anderen Systemen zu finden.
Schon von Anbeginn an enthielt der Dekompressionscode von LZO jedoch eine Sicherheitslücke - jedenfalls, wenn man der Erklärung des Sicherheitsforschers Don A. Bailey glaubt. Sie wurde nicht erkannt, weil die Bedingungen, unter der sie auftritt, komplex sind. Es gibt jedoch auch eine andere Ansicht: Sie wurde nicht erkannt, weil sie rein theoretisch ist. Das ist auch die Meinung von Markus Oberhumer selbst, der zwar Version 2.07 mit einer Korrektur der Lücke veröffentlicht hat, aber dazu schreibt, dass er kein Programm kenne, das betroffen wäre. Es handle sich nur um einen potentiellen Zahlenüberlauf. Um diesen Überlauf auszulösen, muss man auf einem 32 Bit-System einen über 16 MB langen Datenblock an LZO übergeben. Alle bekannten Implementationen setzen jedoch wesentlich kleinere Limits für Datenblöcke - das höchste Limit beim standardisierten Streaming-Format beträgt 8 MB.
Die Art und Weise, wie Don Bailey die Lücke publizierte, wurde von Yann Collet heftig kritisiert. Auf den ersten Blick scheint seine Erläuterung Hand und Fuß zu haben. Im Detail beschreibt Bailey, in welchen Code-Teilen die Lücke steckt, und wie man sie ausnutzen kann. Danach analysiert er, welche Implementierungen potentiell gefährdet sind, wobei er zwischen verschiedenen Auswirkungen unterscheidet. So könnte die Lücke im schlimmsten Fall ausgenutzt werden, um Code in ein System einzuschleusen und diesen auszuführen. Teilweise kann die Zielanwendung auch nur zum Absturz gebracht oder ihre Daten verfälscht werden. In jedem Fall ist ein manipulierter Datenblock von mehr als 16 MB nötig, der spezifisch an die jeweilige Implementierung angepasst sein muss.
Ein Detail hat Bailey dabei allerdings übersehen: Alle bekannten Anwendungen setzen Limits für den Datenblock, die weit unter 16 MB liegen. Was Yann Collet außerdem sauer aufstößt, ist, dass Bailey zwar einige Credits gibt, das Finden des Fehlers aber überwiegend als eigene Leistung darstellt. Dabei sei das Problem schon vor einem Jahr von Ludwig Strigeus erkannt worden, der auch Patches bereitstellte. Für Collet dient Baileys Artikel hauptsächlich zur Selbstdarstellung und Kundengewinnung, ein Verhalten, das von Linus Torvalds einst als »Security Circus« bezeichnet wurde. Außerdem würde durch diesen unverhältnismäßigen Alarm, der auf keinen Fall ein zweites Heartbleed sei, die Wichtigkeit von künftigen Alarmen abgewertet.
Collets Aussage, dass der Code bereits früher gepatcht wurde, scheint allerdings fragwürdig und steht im Gegensatz zu Baileys Angaben. Daher ist in den nächsten Tagen mit einer Anzahl von Updates zu rechnen, ungeachtet dessen, ob die Lücke tatsächlich irgendwo ausnutzbar ist.
){kind=small}
