Integer-Overflow: Sicherheitslücke in Kompressionsverfahren LZ4 und LZO

Im Code für die weit verbreiteten Kompressionsverfahren LZO und LZ4 ist eine Sicherheitslücke entdeckt worden. Das betrifft zahlreiche Anwendungen, darunter den Linux-Kernel, die Multimediabibliotheken FFmpeg und Libav sowie OpenVPN.

Artikel veröffentlicht am 26. Juni 2014, 23:35 Uhr, Hanno Böck

Curiosity benutzt den LZO-Algorithmus, in dem eine Sicherheitslücke gefunden wurde. (Bild: NASA)

Der Linux-Kernel, die Multimedia-Bibliotheken FFmpeg und Libav, OpenVPN sowie zahlreiche weitere Anwendungen sind von einer Sicherheitslücke in den Kompressionsalgorithmen LZO und LZ4 betroffen. Veröffentlicht wurde die Lücke von Don Bailey von der Firma Lab Mouse Security. Sie lässt sich im Linux-Kernel vermutlich nur in seltenen Fällen ausnutzen. Bei FFmpeg und Libav ist das Problem gravierender.

Kompressionsverfahren 1994 entwickelt

LZO ist ein Kompressionsverfahren, 1994 vom Österreicher Markus Oberhumer entwickelt wurde. Es handelt sich dabei um eine Weiterentwicklung der Lempel-Ziv-Algorithmen LZ77 und LZ78. Oberhumer selbst hat eine C-Implementierung von LZO unter der GNU General Public License als freie Software veröffentlicht. LZ4 ist eine Weiterentwicklung des Codes von LZO.

LZO ist weit verbreitet. Laut dem Blogbeitrag bei Lab Mouse Security verwendete sogar der Mars-Rover Curiosity zur Datenübertragung diesen Kompressionsalgorithmus. Außerdem wird der Code von LZO und LZ4 von zahlreichen freien Softwareprojekten verwendet. Alle sind damit potentiell von der entdeckten Sicherheitslücke betroffen.

Im Linux-Kernel dürften die Konsequenzen jedoch überschaubar sein: Die Kompressionsverfahren werden meistens nur dafür verwendet, den Kernel selbst oder das sogenannte Initramfs zu komprimieren. In beiden Fällen hat ein Angreifer üblicherweise keine Möglichkeit, manipulierte komprimierte Daten vom Kernel dekomprimieren zu lassen. Bailey weist in seinem Blogeintrag darauf hin, dass die Ausführung von Code wahrscheinlich nicht möglich ist und 64-Bit-Systeme nicht betroffen sind.

Bei den Multimediabibliotheken FFmpeg und Libav sind die Konsequenzen gravierender: Hier ist die Ausführung von bösartigem Code möglich. Besonders gravierend ist es, wenn ein auf FFmpeg oder Libav basierender Videoplayer als Browserplugin eingesetzt wird. Bailey schreibt, dass bei manchen Linux-Distributionen Mplayer2 in der Standardinstallation samt passendem Browserplugin installiert wird.

Zur Ausnutzung der Sicherheitslücke in OpenVPN sind bislang keine Details bekannt. Weitere Programme, in denen der Code verwendet wird, sind unter anderem Grub und Busybox. Der Debian-Entwickler Yves-Alexis Perez hat eine umfangreiche Liste mit betroffenen Programmen erstellt.

Details zur Ausnutzung später

Don Bailey hat bislang keine Details zur Ausnutzung der Lücke bekanntgegeben. Er will damit warten, bis korrigierte Versionen von den meisten betroffenen Programmen zur Verfügung stehen.

Die Lücke im Kernel-Code haben die IDs CVE-2014-4611 (LZ4) und CVE-2014-4608 (LZO) erhalten. Die Lücke in FFmpeg hat die ID CVE-2014-4610, in Libav die ID CVE-2014-4609 und im originalen LZO-Code die ID CVE-2014-4607.

Der Linux-Kernel behebt die Sicherheitslücken sowohl im LZO als auch im LZ4-Code mit der Version 3.15.2. Vom originalen LZO-Code gibt es die korrigierte Version 2.07. Für den originalen LZ4-Code gibt es bislang keine Korrektur. Von FFmpeg wurde die korrigierte Version 2.2.4 veröffentlicht. In LibAV wurde der Fehler im Git-Repository behoben, eine neue Version gibt es jedoch noch nicht.

Nachtrag vom 27. Juni 2014, 11:12 Uhr

Der Entwickler des LZ4-Codes, Yann Collet, hat in seinem Blog auf die Sicherheitslücke reagiert. Er weist darauf hin, dass die Lücke ursprünglich nicht von Bailey, sondern von Ludvig Strigeus, dem Entwickler von µTorrent, entdeckt wurde. Außerdem sei der Fehler in LZ4 aufgrund der Blockgröße überhaupt nicht ausnutzbar, schreibt Collet. Trotzdem wurde der Fehler jetzt auch dort behoben.

Bailey kommentierte die Vorwürfe von Collet auf der Mailingliste oss-security und erläuterte, warum er die Sicherheitslücke für gravierender hielt. Außerdem lieferte er noch einen Beispiel-Exploit für den LZ4-Code im Linux-Kernel.