Videolan: Eine VLC-Lücke, die keine ist
Vor rund vier Wochen ist ein Fehler an die Entwickler des VLC-Players gemeldet worden(öffnet im neuen Fenster) , der diesen angeblich zum Absturz bringt. Die US-Behörde NIST(öffnet im neuen Fenster) hat dies anschließend als extrem kritische Sicherheitslücke (CVE-2019-13615) eingestuft und auch das Cert Bund(öffnet im neuen Fenster) hat den Fehler zunächst mit einem hohen Risiko bewertet. Viele verschiedene Medien haben diese Warnungen offenbar ungeprüft übernommen. Das Videolan-Projekt beschwert sich nun öffentlich über die falschen Darstellungen - wohl zu Recht.
Anders als in dem ursprünglichen Bugreport dargelegt, stürzt der VLC-Player mit der aktuellen Version 3.0.7.1 aber nicht ab. Die Entwickler aus dem Videolan-Projekt haben entsprechend Probleme, den Fehler überhaupt nachvollziehen zu können, wie aus der Diskussion im Bugtracker des Projekts hervorgeht.
Auch wir können einen Absturz des VLC-Players mit der im Bugtracker bereitgestellten Datei nicht nachstellen. Die Mühe, den Fehler zu verifizieren und nachzustellen, haben sich aber offenbar weder die Behörden noch die vielen Medien gemacht, die inzwischen über den Fehler im VLC-Player berichtet haben.
Das Videolan-Projekt geht inzwischen davon aus, dass sich der von dem Ersteller des Berichts vermeintlich gefundene Fehler in der Bibliothek Libebml aus dem Matroska-Projekt befindet. Diese nutzt der VLC-Player lediglich als Abhängigkeit, ebenso wie einige andere freie Multimediaprojekte, wie etwa FFMpeg oder Gstreamer.
Das Matroska-Projekt weist aber explizit darauf hin(öffnet im neuen Fenster) , dass das gemeldete Problem schon vor über einem Jahr behoben worden ist. Dieses Update hat auch das Videolan-Projekt für seine offiziellen Builds seit Version 3.0.3 übernommen. Einige Linux-Distributionen scheinen das Update jedoch noch nicht an ihre Nutzer ausgerollt zu haben. Ein akute und gefährliche Sicherheitslücke - wie von vielen Medien berichtet - existiert mit aktuellen Versionen des VLC-Players also nicht.
Speicherleck in aktueller Version
Wie aus dem VLC-Bugtracker darüber hinaus hervorgeht, haben die Videolan-Entwickler mit der bereitgestellten Datei jedoch ein Speicherleck ausfindig machen können. Unter Windows und Linux führt das Ausführen der Datei in einer Schleife zu einem immer wiederkehrenden Speicherleck, so dass der VLC-Player nicht mehr genutzt werden kann. Unter Linux wird der Prozess des VLC-Players irgendwann vom Out-of-Memory-Killer des Kernels(öffnet im neuen Fenster) zwangsweise beendet.
Dieses fehlerhafte Verhalten ließe sich als Denial-of-Service-Angriff auf den VLC-Player ausnutzen. Dazu müssten Nutzer aber dazu gebracht werden, die speziell manipulierte Datei eben in einer Schleife auszuführen. Und selbst dann lässt sich der VLC-Player einfach über das Betriebssystem beenden und danach weiter wie gewohnt verwenden. Eine gravierende Sicherheitslücke ist auch das nicht. Die Behörden und die Berichterstattung vieler Medien scheint das aber kaum zu interessieren.
Deutliche Kritik an Behörden und Medien
Das Cert Bund warnt vor dem vermeintlichen Fehler damit, dass dieser ausgenutzt werden kann, um beliebigen Schadcode auszuführen, was aber eben mit der aktuellen Version der Bibliothek nicht der Fall ist. Bei Client-Anwendungen wie dem VLC-Player müssen wie erwähnt außerdem zum Ausnutzen einer Lücke Nutzer immer noch dazu gebracht werden, die manipulierten Dateien abzuspielen.
Einige Medien verwenden in ihrer Berichterstattung außerdem den Begriff Remote Code Execution (RCE). Damit werden eigentlich gravierende Sicherheitslücken bezeichnet, die es Angreifern ermöglichen, eben ohne Zutun der Nutzer Schadcode auf Rechnern aus der Ferne auszuführen. In den allermeisten Fällen betrifft dies Server-Systeme. Diese Beschreibung ist für die Fehler im VLC-Player also auch völlig irreführend. Einige Medien empfehlen ihren Nutzern sogar eine Deinstallation des VLC-Players, was angesichts des Fehlers eine völlig überzogene Reaktion ist.
Zwar hat zumindest das Cert Bund inzwischen vorsichtig reagiert und bewertet das Risiko des Fehlers nur noch als mittelschwer statt wie bisher hoch. Auf Nachfrage von Golem.de kritisiert der Videolan-Chefentwickler Jean-Baptiste Kempf aber, dass der Eintrag vom Cert Bund immer noch auf den VLC-Player verweist, nicht aber auf die tatsächlich betroffene Bibliothek aus dem Matroska-Projekt. Angesichts des auftretenden Speicherlecks sei außerdem die Risikobewertung des Cert Bund immer noch zu hoch.
Derartige Kritik äußert das Videolan-Projekt auch auf seinem offiziellen Twitter-Kanal(öffnet im neuen Fenster) . Dort wird außerdem die Organisation zur Vergabe der CVE-Nummern, Mitre, sowie das NIST massiv kritisiert. Diese hätten sich vor Veröffentlichung ihrer Bekanntmachungen nicht mit dem Videolan-Projekt in Verbindung gesetzt.
Das widerspreche zwar den eigenen Richtlinien von Mitre, geschehe laut Aussage der VLC-Entwickler jedoch schon seit Jahren. Ebenso sei auch das NIST nicht kooperationsbereit und gebe dem Videolan-Projekt nicht die Möglichkeit, falsche Informationen in deren Sicherheitswarnungen zu korrigieren. Auch auf eine aktuelle Anfrage zu dem Fehler hätten weder Mitre noch das NIST reagiert.
Für das gemeinnützige Videolan-Projekt ist solch ein Verhalten offizieller Stellen sowie auch vieler Medien besonders ärgerlich, da das Team aus Freiwilligen eben kaum Möglichkeiten hat, den dadurch angerichteten Schaden an der öffentlichen Wahrnehmung des Projekts zu beheben.
Nachtrag vom 25. Juli 2019, 8:42 Uhr
Das Cert Bund hat seine Risikobewertung für den ursprünglichen Fehler inzwischen erneut nach unten korrigiert und hält das Risiko der Lücke nun nur noch für niedrig. Auch das Nist hat seinen Bericht zu dem Fehler nun geändert und bewertet die Lücke nur noch als mittelschwer. Die US-Behörde verweist außerdem darauf, dass der Fehler in der Libebml vor Version 1.3.6 gesteckt hat und der Fehler seit Version 3.0.3 im VLC-Player behoben ist.