- FFmpeg ist ein zentrales Open-Source-Framework für die Medienverarbeitung weltweit und ein unverzichtbarer Baustein, der von großen Diensten wie VLC, Chrome und YouTube genutzt wird
- Kürzlich entdeckte Googles KI-basierter Sicherheitsscanner einen kleinen Bug im Zusammenhang mit einem Spiele-Codec aus dem Jahr 1995, was die Debatte darüber anheizte, dass Großunternehmen freiwilligen Entwicklern eine übermäßige Last aufbürden
- FFmpeg erklärt, das Projekt werde fast vollständig von Freiwilligen gepflegt, und Google solle nicht nur Schwachstellen melden, sondern auch Patches liefern oder finanzielle Unterstützung leisten
- Google betonte mit Verweis auf die Offenlegungsrichtlinie von Project Zero und das Patch Rewards Program seinen Beitrag zu transparenter Sicherheit, doch die FFmpeg-Community kritisierte die Vergütungsgrenzen und die mangelnde praktische Unterstützung
- Der Streit macht die Probleme von massiv durch KI erzeugten CVEs und der Nachhaltigkeit der Open-Source-Wartung sichtbar und führt zu einer Debatte über die Verantwortung großer Tech-Unternehmen
Überblick über den Konflikt zwischen FFmpeg und Google
- FFmpeg ist ein Open-Source-Multimedia-Framework, das Transkodierung, Wiedergabe und Streaming von Audio- und Videodateien unterstützt
- Zentrale Bibliotheken wie libavcodec und libavformat werden in VLC, Kodi, Plex, Chrome, Firefox und YouTube verwendet
- Doch wie viele andere große Open-Source-Projekte leidet auch FFmpeg unter akutem Geldmangel
- Auf Twitter entbrannte zwischen FFmpeg, Google, Chainguard und Sicherheitsforschern eine Debatte über die Art der Offenlegung von Sicherheitslücken und die Verantwortung dafür
- Im Mittelpunkt stand, dass massenhaft von KI erzeugte Schwachstellenmeldungen oft nur einen geringen tatsächlichen Wert haben
Auslöser der Kontroverse: ein kleiner Bug, entdeckt von Googles KI
- Googles KI-Agent entdeckte in FFmpeg einen Bug bei der Dekodierung des LucasArts-Smush-Codecs
- Das Problem ist eine Schwachstelle mittlerer Schwere, die nur die ersten 10 bis 20 Frames des Spiels Rebel Assault 2 von 1995 betrifft
- Die FFmpeg-Entwickler patchten den Fehler, kritisierten die ineffiziente Meldung jedoch als „CVE slop“
- FFmpeg verweist mit „FFmpeg aims to play every video file ever made“ auf sein Ziel perfekter Kompatibilität, merkt aber an, dass ein Großteil des Codes in Assembler geschrieben sei und deshalb schwer zu warten ist
Die Belastung für Open-Source-Maintainer
- Die FFmpeg-Community kritisiert, dass Großunternehmen, die FFmpeg nutzen, wie etwa Google, die Behebung von Schwachstellen auf unbezahlte Freiwillige abwälzen
- Nach ihrer Auffassung sollte Google bei Schwachstellenmeldungen zugleich Patches bereitstellen oder finanzielle Unterstützung leisten
- Als ähnlichen Fall nennt sie den Maintainer von libxml2, Nick Wellnhofer, der wegen wiederholter Sicherheitsmeldungen Dritter angekündigt hat, die Wartung einzustellen
- Er erklärte, es sei nicht nachhaltig, dass unbezahlte Freiwillige jede Woche mehrere Stunden für die Bearbeitung von Sicherheitsproblemen aufwenden müssen
Streit um die Offenlegungsrichtlinie von Google Project Zero
- Im Juli 2025 führte Google Project Zero (GPZ) die Richtlinie „Reporting Transparency“ ein
- Nach Entdeckung einer Schwachstelle erfolgt die Veröffentlichung innerhalb einer Woche, anschließend startet automatisch eine Frist von 90 Tagen zur Behebung
- Auch wenn noch kein Patch bereitsteht, wird die Veröffentlichung fortgesetzt, was laut Kritikern Freiwilligenprojekte übermäßig unter Druck setzt
- FFmpeg fragt provokant, ob es fair sei, dass KI Sicherheitsprobleme in Hobby-Code aufspürt und Freiwillige zur Behebung auffordert
- Zwar gibt es Googles Patch Rewards Program, doch FFmpeg bemängelt, es sei „mit Grenzen wie drei Fällen pro Monat praktisch keine echte Hilfe“
Gegensätzliche Sichtweisen und die Nachhaltigkeit von Open Source
- Dan Lorenc von Chainguard verteidigte Googles Rolle mit dem Argument, auch die Offenlegung von Sicherheitslücken sei ein Beitrag zu digitalen öffentlichen Gütern
- Er sagte, Google gehöre zu den Unternehmen, die Open Source am aktivsten unterstützten, und solche Debatten könnten Sponsoren eher abschrecken
- FFmpeg betont dagegen, dass Personal und Geld fehlen, um auf große Mengen KI-generierter CVEs zu reagieren
- Sicherheitsexperten erkennen an, dass die Offenlegung von Schwachstellen notwendig ist, weil FFmpeg ein zentraler Bestandteil der Internet-Infrastruktur ist
- Am Ende des Artikels wird betont, dass zentrale Open-Source-Projekte ohne echte Unterstützung großer Unternehmen nicht aufrechterhalten werden können, und mit Verweis auf den Fall libxml2 die Notwendigkeit nachhaltiger Förderstrukturen hervorgehoben
15 Kommentare
Hoffentlich endet das nicht am Ende in einem Zerwürfnis wie zwischen der WordPress-Stiftung und dem Unternehmen WP Engine?
Das scheint die Fortsetzung von
https://daniel.haxx.se/blog/2024/…
zu sein.
Wenn es in dem obigen Text um komplett falsche Reports von Einzelpersonen ging, die auf Bug-Bounties aus waren, dann handelt es sich im Fall von FFmpeg um gültige, aber geringfügige Reports eines Großunternehmens.
Muss man unbedingt darauf reagieren, nur weil Google es beanstandet?
Da die Schwachstelle selbst bereits öffentlich geworden ist, scheint es unvermeidlich zu sein, darauf reagieren zu müssen.
Ach so … diesen Blickwinkel gab es also. Danke, dass Sie mich darauf hingewiesen haben!
Das ist also der Punkt, an dem eine veröffentlichte Sicherheitslücke für Angriffe ausgenutzt werden könnte, hui …
Eigentlich könnte man auch sagen: Ob das öffentlich wird oder nicht, wenn es euch wichtig ist, behebt es eben selbst~ Aber ich denke, dass es gerade den Maintainern zu verdanken ist, die nicht so ticken, dass sich das Projekt bis hierhin entwickeln konnte.
Aha ... ich glaube, Sie haben recht.
Ich habe wohl zu sehr aus meiner eigenen Perspektive gedacht.
Vielen Dank für Ihren Hinweis!
Hacker-News-Kommentare
Ein Punkt im Artikel ist mir besonders aufgefallen. Innerhalb von Amazon musste Mark Atwood seinen Vorgesetzten offenbar erklären, dass man Entscheidungen rund um FFmpeg nicht blockieren könne, weil „sie kein Vendor sind, es kein NDA gibt und wir keinen Einfluss auf sie ausüben können“.
Ich stimme der Haltung zu, dass man nicht nur Probleme bringen, sondern auch Lösungen mitbringen sollte, aber wenn Google Geld dafür hat, Bugs zu finden, dann kann es auch Geld dafür ausgeben, sie zu beheben.
So ist man nicht auf private Patches angewiesen, kann dem Projekt etwas zurückgeben, von dem man ursprünglich profitiert hat, und es ist auch ethisch das Richtige.
In der Praxis war das Problem jedoch oft, dass Compliance- oder Prozesshürden innerhalb von Unternehmen Upstream-Beiträge erschweren.
Ich habe mir einmal eine satirische Lizenz vorgestellt, nach der Mitarbeitende von S&P-500-Unternehmen bei einer Bug-Meldung einen bestimmten Betrag spenden müssten und unterhalb eines gewissen Betrags innerhalb eines bestimmten Zeitraums keine Antwort erwarten dürften.
Wenn Unternehmen ungern betroffen sind, zögern sie schließlich auch nicht, Software intern geschlossen zu halten oder auf AGPL umzustellen, also ist es jetzt an der Zeit, dass sie direkt dafür zahlen.
Als Open-Source-Maintainer kann ich gut nachvollziehen, dass es sich so anfühlt, als würden große Unternehmen kostenlose Arbeit erzwingen, indem sie Sicherheitsprobleme offenlegen.
In der Praxis ist es aber so, dass ich Sicherheitsprobleme am Ende ohnehin beheben muss, egal wer sie gemeldet hat.
Es ist auch in Ordnung, wenn ein Projekt Sicherheit nicht priorisiert, aber dann muss es auch das entsprechende Reputationsrisiko tragen.
Bei kommerziellen Unternehmen ist die Forderung nach schnellen Fixes nachvollziehbar, aber an freiwilligengetragene OSS-Projekte dieselbe Anforderung zu stellen, ist unrealistisch.
Er soll nur in den ersten 10 bis 20 Frames eines Spiels von 1995 auftreten, daher wirkt die Einstufung als „mittlere Schwere“ überzogen.
Das sieht nach einem Fall aus, der nur die Zeit der Maintainer verschwendet.
Wenn es ernst ist, ist es gut, wenn es irgendjemand meldet, und wenn es belanglos oder falsch ist, kann man es ignorieren.
Letztlich muss das Projekt selbst entscheiden, welche Bugs es behebt.
Ich unterstütze die Position des FFmpeg-Teams. Viele Unternehmen nutzen FOSS nur für Marketing-getriebene Imagepflege und tragen in Wirklichkeit nichts bei.
Früher hätten manche schlicht raubkopiert, heute können sie dank der Lizenz ohne schlechtes Gewissen davon profitieren.
Dass sogar Codecs getestet werden, die intern gar nicht genutzt werden, dient rein dem öffentlichen Interesse.
Natürlich könnte Google FFmpeg finanziell stärker unterstützen, aber ich bin nicht dafür, diesem konkreten Maintainer direkt Geld zu geben.
Sie erlaubt freie Nutzung, lässt aber auch Missbrauch zu.
GPL 3 wird zwar oft als überzogen kritisiert, hatte aber zumindest die Absicht, Ausbeutung zu verhindern.
Da sind Menschen, die kostenlos Software entwickeln, die eine Ära prägt, und Unternehmen, die daraus den gesamten Wert abschöpfen.
Die einen handeln aus Leidenschaft, die anderen transaktional.
Gegenüber großen Unternehmen ist öffentliche Schwachstellenoffenlegung nötig, aber bei ressourcenschwachem OSS kann sie mehr Risiko als Nutzen bringen.
Wenn Google schnelle Fixes will, sollte es auch den Patch mitliefern, dann profitieren alle.
Gerade wenn es sich um Schwachstellen handelt, die ein LLM finden kann, ist es wahrscheinlich, dass sie irgendwann ausgenutzt werden.
Durch die Veröffentlichung können sich Nutzer selbst schützen, und dass FFmpeg sich entschieden hat, das Problem zu beheben, war eine freiwillige Entscheidung.
Sicherheitsforschung selbst ist eine teure Form des Beitragens zu Open Source.
Forschenden zu sagen, ihr Beitrag reiche nicht aus, bedeutet letztlich wiederum, von Freiwilligen kostenlose Arbeit zu verlangen.
Die Transparenz von FOSS hilft eher dabei, das Sicherheitsbewusstsein zu schärfen.
Die Grauzonen der Realität werden dabei nicht anerkannt.
Wenn „eine einzige E-Mail drei Produktlinien stoppen kann“, dann wären 10.000 bis 20.000 Dollar Förderung pro Jahr schon als Versicherung günstig.
Wenn Google und Amazon jeweils nur 50.000 Dollar beisteuern würden, könnten FFmpeg-Entwickler stabil arbeiten,
und gerade Google, das YouTube betreibt, könnte ohne Weiteres 100.000 bis 200.000 Dollar zahlen.
Es wurde ein Twitter-Thread des Google-Sicherheitsverantwortlichen geteilt, der die Beiträge an FFmpeg zusammenfasst.
Dass ein Billionen-Dollar-Unternehmen nicht genug Personal oder Geld haben soll, ist wenig überzeugend.
Ich frage mich, was genau das Ziel von Project Zero ist.
Ich würde gern wissen, ob dahinter mehr steckt als nur das Finden von Schwachstellen.
Gleichzeitig ist es nützlich für die Anwerbung von Security-Talenten und das Reputationsmanagement.
Wenn dafür genug Spielraum da ist, sollte meiner Meinung nach aber auch in das Schreiben von Patches investiert werden.
Die betreffende Schwachstelle war ein Use After Free, und Googles AI hat sie gefunden.
Die Behebung dürfte aber keine drei Sekunden dauern.
Es ist unerquicklich, wenn ein Unternehmen mit unbegrenzten Mitteln einem Freiwilligenprojekt spamartige Bug-Reports vor die Füße wirft.
Das reicht kaum für eine Einstufung als CVE; ein gewöhnlicher Bug-Report wäre ausreichend gewesen.
freeverzögern“.Um Speicherlecks zu vermeiden, ist eine komplexere Änderung nötig.
Vermutlich ist es ohnehin der richtige Weg, diesen Codec standardmäßig deaktiviert zu lassen.
Man gibt ihnen etwas zu essen, und dann verlangen sie gleich den ganzen Sack.
Bug-Reports sind doch eindeutig auch ein wichtiger Beitrag ...
Es fühlt sich ungefähr so an, als würde jemand freiwillig die Nachbarschaft sauber machen, und dann kommt der örtliche Großgrundbesitzer, dem das meiste Land dort gehört, zu der putzenden Person und sagt: Da drüben in der Ecke liegt noch eine Zigarettenkippe.
Ich denke auch, dass diese Analogie zutrifft.
Eine passende Analogie.
Ist das wirklich ein so großes Problem? Wenn man es liest, handelt es sich um eine Sicherheitslücke mittlerer Einstufung, die nur in den ersten 10 bis 20 Frames eines bestimmten klassischen Spiels relevant ist. Halten Sie das wirklich für einen wichtigen Beitrag für FFmpeg? Der wichtigste Beitrag für die Open-Source-Community dürfte doch sein, sie so zu unterstützen, dass eine stabile Entwicklung möglich ist — besonders, wenn es sich um ein Unternehmen handelt, das die Ergebnisse intensiv nutzt; das sollte meiner Meinung nach Vorrang haben.
Wegen solcher Leute wurde XZ mit einer Backdoor versehen.
Der Bug-Report selbst ist zwar erstklassig, aber wenn dann überall herumposaunt wird, dass auf eine schwerwiegende Schwachstelle in einem Videoformat aus der Kennedy-Ära nicht fristgerecht reagiert wurde, ist das eben das Problem.
Man gibt ihnen nicht etwas, das sie essen können, sondern etwas, das sie essen müssen, und fragt dann, warum sie es nicht innerhalb der Frist geschafft haben.
FFmpeg hat nur begrenzte personelle Ressourcen. Ist es da richtig, dass Google mithilfe von AI Dutzende Bug-Reports zu Formaten ausschüttet, die inzwischen kaum noch verwendet werden, und dann Druck macht, alles innerhalb der Frist zu beheben?