FFmpeg vs. Google: balhé a Big Sleep „CVE slop” bugjelentései körül

Címkék

Nyílt konfliktus alakult ki az FFmpeg fejlesztői és a Google között, miután a Google Project Zero és a DeepMind közös AI-eszköze, a Big Sleep sebezhetőséget jelentett egy őskövület formátumban: a LucasArts Smush kodekben.

A baj nem a buggal, hanem a Google folyamatával van: a Google Project Zero 2025-ös „Reporting Transparency” szabályai szerint egy héten belül nyilvánosságra hozzák, hogy sebezhetőséget találtak egy adott projektben, elindul a 90 napos disclosure-óra, és név szerint megnevezik az érintett projektet – függetlenül attól, hogy egy pár fős, önkéntes csapatról van szó, amelynek nincs vállalati szintű kapacitása ezek azonnali kezelésére. Az FFmpeg fejlesztők a levelezőlistán („fuzzer and security issues / Big Sleep” thread) és X-en már nyíltan „CVE slop”-nak nevezik az ilyen, gyakorlatban alig kihasználható hibák köré épített CVE-gyártást.

A hibákat ettől függetlenül javítják – erre példa az avcodec/exr patch, „Found-by: Google Big Sleep” megjelöléssel –, de egyre hangosabb az üzenet: ha a Google AI-val tömegesen túrja fel a kódot, és elvárja a gyors, „enterprise” szintű reakciót, akkor finanszírozza is az FFmpeg-et. Ha pedig nem fizet, akkor a fejlesztők szerint itt lenne az ideje visszavenni az AI-generált CVE-esőből – ahogy azt a The New Stack összefoglalója is kiemeli.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

Hozzászólások

Jó-jó. De akkor végül is igaza volt az AI-nak? 

Valóban, bactatás helyett jobb lenne, ha küldene egy levelet csak a fejlesztő csoportnak, hogy: 

Srácok az AI-nk talált ilyen, meg ilyen sebezhetőségeket, ha akartok még keresni párat, akkor elő tudtok fizetni a rendszerünkre. 

Puszi: 

Alphabet

Amúgy az ffmpeg szerintem egy elég komoly projekt a biztonság szempontjából, mert sok helyen ott van, más kérdés, hogy boldog-boldogtalan ingyen használja és ha ki is jönne javítás, nem biztos, hogy ezek azonnal alkalmaznák is.

Szerintem ez nem fekete-fehér, hogy amint találunk egy bugot, máris világvégét kiabáljunk. Ez olyan, mintha egy AI orvos egy tüsszentés miatt automatikus karantént írna elő.

Mennyire para a bug? Mennyire lehet kihasználni? Reálisan mekkora a veszély? Milyen érték jön ki a károkozás bekövetkezésének és a kár mértékének a szorzatára?

Amíg ezek a kérdések nem tiszták, addig csak riogatás megy. Ja, amúgy most mondom, hogy mindenki meg fog halni aki ezt a hozzászólásomat olvassa. De mondok még durvábbat. Azok is, akik nem olvasták soha. Ez tuti, és nem vicc, mert 200 év múlva garantáltan mindmeghalunk. Na, akkor lehet rettegni. :-)

Ha az AI talál egy bugot, akkor jó lenne, ha nem csak annyi jönne ki belőle, hogy "ez szar", hanem az is, hogy "és ezt az if -et kell átírni, hogy jó legyen". Az előremutató lenne.

Mennyire lehet kihasználni?

Gondolom azután, hogy publikálták, igen könnyen. Mert addig senkinek eszébe nem jutna valami ősi soha nem használt kodekkel videót csinálni. Most meg már igen. 

Itt ugye az eljárás a problémás. Ráeresztik a nagyteljesítményű AI-t a hobbiprojekt kódbázisára, aztán olyan határidőkkel hozzák nyilvánosságra, amennyi idő alatt még csak egy emailre sem biztosan fognak válaszolni (mert nem fizetett alkalmazottak). 

Igazának igaza volt, csak itt nem ez az érdekes :)

Egyrészről az egy valóban fontos, és hasznos dolog, hogy felkutassuk a sebezhetőségeket. Annak is van értelme, hogy ezt a gugli az elérhető eszközeivel fullba tolja, amennyire tudja, hiszen ha ő nem, hát majd más megcsinálja ezt az AIs turkálást, a lehetőség adott, értem, hogy elé kell menni.

Őszintén szólva én azt is értem, hogy a secu teamek olyan policykat tolnak -- és ez azért már nem új -- hogy jeleztük, van X idő, aztán public. Mert előtte azért egyáltalán nem volt példa nélküli, hogy a kedves vendorok meresztették a seggüket, hogy majd a következő fél éves releasebe, hopp kimaradt, plz még. És ezt egyébként jellemzően a nagyok csinálták, pl MS, akik egy ponton kénytelen voltak ezzel kezdeni valamit emiatt. (És persze azért a gugli kurva jó abban, hogy úgy csináljon public good-ot, hogy azért abból lehetőleg neki jó legyen, lásd pl cert transparency, aminek a "mellékhatása", hogy azonnal tud értesülni bármilyen új oldalról, vagy itt, hogy hát ezzel azért lehet zsarolni az MS-t).

A másik oldalról viszont ott van az, hogy ha megnézed, hogy a konkrét issue arról szól, hogy van egy 30 éves játékban egy spec codec, IRL kizárólag annak a videóit érint. Medium impact, ami valahogy high lett, mire CVE-t kapott. (8.7 pont, faszod)

Namost, egyrészt,  ha ezt így elkezdi kiönteni magából a gugli, akkor azzal egészen konkrétan hülyére lehet baszni a CVE rendszert, amitől senkinek nem lesz jó, sőt. Lehet nem lenne baj, ha valaki gondolkozna azon, hogy ha lett kapacitás hirtelen arra, hogy az elmúlt 30 év felgyülemlett szénakazlát most jól át tudjuk túrni tűk után, akkor talán át kéne gondolni, hogy ezt hogy kell aztán kezelni. Mert ez most kicsit olyan, hogy ízlett a kétszer csípős mexikói kaja, beütött a tekila is, uh jó ötletnek tűnik belefosni a ventilátorba ...

Másrészt teljesen érthető a kiakadás, hogy jön a gugli, előkapar nagy tételben ilyen faszságokat, és elvárja, hogy te ezzel foglalkozz, de izibe ám, mert különben kiteszünk a publikus szégyenfalra. Csinálni meg valamit azoknak, aki pénzt keresnek vele, hát azt nem nagyon akarózik (I spent about a week at year at my time at @amazon preventing  us from accidentally fucking over @FFmpeg. I usually had to start each conversation with "They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me...")

Őszintén szólva, ha én lennék az ffmpeg, lehet, hogy szépen széttárnám a kezem, és nem rohannék sehova. Ha lejár az idő, lejár az idő, majd lesz benne aktívnak jelzett CVE. Aztán majd mikor már elég sok lesz, akkor nyugodtan odamehet a gugli security másik lába mondjuk a youtubeosokhoz (vagy az amazon secusa a primeosokhoz), hogy hát ecsém, ez lukas mint a szita, ezt így nem használhatjátok, mi a terv? Aztán majd kiderül, hogy mégiscsak van erőforrás, vagy funding. Legalább arra, hogy megtanulja a tűkereső, hogy mi számít igazából mediumnak :) )

(Zárójel: én egyébként ezt a funding hisztit is kevésbé értem: megint csak, ha én lennék az ffmpeg, akkor speciel az a hátam közepére se hiányozna, hogy ilyenkor valaki jöjjön, hogy tessék itt egy csekk, de akkor most a hobiprojektedben időre CVE-ket fog kergetni, mint egy hasznos kis rabszolga.)

Teljesen jó hozzáállás. Ez egy full ingyenes modul, amit egy kanyi buznyák nélkül használ a fél internet, olyan óriás cégekkel, amiknek a kerekítési hibaszázaléka a költségvetésben is egy kisebb afrikai ország büdzséje nagyjából.

Már pedig ha ennyi erőforrásuk van, akkor egy ilyen után ezt úgy illene csinálni, ahogy itt is írta már valaki, hogy: "Sziasztok, itt ez a bug, javítani kellene. Hogyan tudunk ebben legjobban segíteni? Pénz, paripa, fegyver, mi kell? Ha már ingyen használjuk milliárdok termelésére a cuccot."

Az automatizált hibakeresés nem rossz, de azért ésszel kéne csinálni.

Ha már az AI megtalálta, akkor miért nem generált hozzá patchet is?

Jogos. Legtöbbször ezek a bugok nagyon egyszerűen patchelhetők, csak egy boundary check ellenőrzést kell betenni, vagy átdefiniálni valami változót, ciklust, 1-2 soros szösszenet, ha az AI megtalálta, nyugodtan küldhetnék be rá a megoldást is. Már ha a guglinak ez annyira szívügye.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Ha bedurcázik az ffmpeg core team, és azt mondják h. mindenki b..ssza meg a q..a anyját, és leállnak a fejlesztéssel 1-2-3 évre, akkor a sok ingyenélő (INSERT IDE A VILÁG ÖSSZES CÉGE AKINEK BÁRMILYEN MÉDIAFELDOLGOZÓ TOOL-JA FFMPEG-RE ÉPÜL) mind beszopja, és globálisan mennek felgyújtani a google székházát. Ezt kellene ott google HQ-ban felfogni.

A legeslegrosszabb esetek, továbbgondolva, amit írtál:
 - abandoned lesz a projekt, felkarolja valami profitorientált cég ezt is, és rak rá szépen egy árat innentől.
 - maga az ffmpeg közösség unja meg és árazza be

Ami természetesen az ilyeneknek mint a Google, Microsoft mit számít? Továbbhárítja az árat a termékein keresztül. 

Szal az egész vége megint az lenne, hogy majd mi fizetjük meg ennek a faszkodásnak is az árát...

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Hát, nyilván attól függ, hogy mennyire voltak észnél a licensz környéki jogokkal anno (mivel elég régi, simán lehetnek bajok).

De egyébként pénzessé sem kell feltétlen tenni, de mostanában az egy láthatólag kb működő pénzcsinálási irány szokott lenni ezek a Business Source License-s dolgok, hogy open source ez továbbra is, have fun. Kivéve, ha tényleg sok pénzt kereső cég vagy, akkor nem, akkor itt a kassza. Valami ilyesmit el tudnék képzelni, mint egy valamennyire működő módszertant, úgy általában is. Ki kell hozzá találni valami jó alapítványi non profit struktúrát, aki kezeli a bevételeket és környékét, hogy ne tartsa távol azokat, akik egyébként nem akarnának bedolgozni feltétlen egy cégnek.

Sajnos az látszik, hogy most elég nagy tételben van már sok olyan kisebb szoftver, amit vagy simán csak adottnak vesz az üzleti élet (aztán még jön pofázni, lásd topic), meg olyan is, amit valójában jobb volna közös erőből finanszírozni, mert mondjuk nagy (ugye pl a linux kernel tulajdonképp ilyen, csak hát az "csak" egy darabja a kiarkósnak), szóval erre kell valami élhető modellt kitalálni, mert egyébként azért összességében még mindig ez a jobb modell egyszeri embernek is, ha összehasonlítjuk azokkal a területekkel, ahol nem igazán vannak közkincs lehetőségek...

Egyrészt dehogynem létezik, a BSL 1.1-et (amit ugye a mariadb-sek találtak ki), pl a directus így használja: 

Additional Use Grant: You may use the Licensed Work in production as long as your Total Finances do not exceed US $5,000,000 for the most recent 12-month period, provided that Monospace, Inc. will not be liable...

References to“Total Finances” mean the largest of your aggregate gross revenues, entire budget, and/or funding (no matter the source); “you” and “your” include (without limitation) any individual or entity agreeing to these terms and any affiliates of such individual or entity; and “production” mean any use other than (i) development of (including evaluation of the Licensed Work), debugging, or testing your offerings, or (ii) making the Licensed Work available standalone in unmodified object code form.

...

For information about alternative licensing arrangements, please visit our pricing page.

Nem csak arra jó, hogy pl competitiont korlátozz vele, mint ahogy a hashicorp csinálta pl.

De ha ne is létezne még, attól még bizony lehetne ilyet csinálni. Pont vannak ezek a cuccok, hogy apache fundation, meg fsf, meg ilyenek.

Há kérdezzék meg az AI-t arról is, hogy mennyien használják a talált hibát tartalmazó funkciókat és várhatóan mekkora valószínűséggel és mennyi időbe telik majd kijavítani! De akár be is szánthatnák ezt az agyament policy-t (fix várakozási idő és listázgatás mint furkósbot) és bízzák rá a kommunikációt és egyeztetést is az érintett projektekkel a kedves AI-ra - ha valamiért embernek nem megy vagy drága.

Egyebkent mi tortenne, ha nem tudnak kijavitani idore? Semmi.

Ez akkor lenne igaz, ha valami elterjedt médiakódekkel kapcsolatos lenne a hiba, pl. x264 vagy hasonló. A LucasArts Smush kódek olyan ritkaság, hogy most hallok róla először. Nem hinném, hogy életszerű támadási pont lenne. Ennek ellenére elvi szinten tényleg problémás, hogy nonprofit, kis fejleszetői közösségnek lehetetlen határidőt adnak a javításra, genyóság a köbön.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Arpi is a megmondhatója, ha minden nyomorult kodek-ben minden változót és kritikus buffer-t ellenőrző kóddal bástyáznának körbe, akkor talán most 2025-re lennének olyan erős gépek használatban, amik 16 core-al 5,5 Ghz-en le bírnák játszani a 480p DivX-et tuti-safety-biztosan.

Ezt ugy irod, mintha minden szoftver makulatlan lenne. Eleg megnezni nepszerubb szoftverek hivatalos container image-ek vulnerability scan eredmenyeit. Konnyeden talalni olyanokat, ahol 10-20 CVE is van, raadasul meg High es/vagy Critical severity-ju is akad kozottuk. Es ki vannak ezek tiltva barhonnan is? Dehogy.

Ha egy fejlesztő találta volna meg ezt a hibát, akkor mi lenne a fair eljárás? 

kapcsolódik

ír a fejlesztőknek, és a nyilvánosságra hozatal határidejét aszerint határozza meg, hogy milyen projektről van szó. SP500-as cég top terméke? Akkor mehet a furkósbot, mert egy ilyen cégnek lennének erőforrásai arra, hogy security issue-kat sürgősséggel javítsanak. Ingyen dolgozó hobbiprogramozók? Talán érdemes inkább segíŧséget felajánlani és tovább várni. 

Igen, ebben a konkrét esetben úgy lenne elegáns, szimpatikus, és értékteremtő, hogy segítséget ajánlani. A google számára nem lenne vállalhatatlan teher.

Azt viszont nem tartom tisztességtelennek, hogyha egy sérülékenység feltárója azt tapasztalja hogy ignorálják a bejelentését, akkor ha az egy valóban fontos sérülékenység és esetleg szó szerint tömegeket érinthet mint egy ffmpeg sérülékenység, akkor nagyobb körben is szóváteszi. Persze nem akkor ha a googleről van szó, ők meg is javíthatnák azokat a hibákat amiket a mások repoin promózott hibadetektáló rendszerük észrevesz. Az lenne a valódi reklám, ha küldenék is a sérülékenyég mellé a patchet/merge requestet (amit aztán a konkurens cég hibadetektálója tudna vizsgálni, mennyire jó), mert ez így nagyon féllábas. Vagy, futtassák az mi-t a maguk kódjaira, és írják le a techblogjaik valamelyikében az eredményeket.   

Más kérdés, hogy az OSS-nek a teljes kódtranszparencia a velejárója, ami nem feltétlen mindig hasznos, mint most mikor csak a sérülékenység ténye és kiváltásának módja lett publikálva a megoldás nem, de ez egy ilyen konstrukció.

Azt viszont nem tartom tisztességtelennek, hogyha egy sérülékenység feltárója azt tapasztalja hogy ignorálják a bejelentését, akkor ha az egy valóban fontos sérülékenység és esetleg szó szerint tömegeket érinthet mint egy ffmpeg sérülékenység, akkor nagyobb körben is szóváteszi.

Azért ennek ott a másik oldala is, hogy akkor egyébként mit lehet még tenni, hogy mégiscsak javítva legyen. Mert azért alapvetően nem az az oka ám ennek a stratégiának, hogy "köcsögöljünk", hanem az, hogy történjen is valami, mert mint mondtam, korábban ez nem volt, és hát valahogy gyakran voltak kifogások, ezért van a bunkósbot. És hát a kód hibája elsősorban mégiscsak a kód írójának a felelőssége. De igen, látszik, hogy ennek a modellnek valahogyan finomodnia kellene.

Persze nem akkor ha a googleről van szó, ők meg is javíthatnák azokat a hibákat amiket a mások repoin promózott hibadetektáló rendszerük észrevesz.

Azért az se olyan egyszerű, nem az ő kódjuk az, attól se lesz nagy öröm, ha ai generált / valójában elég érdektelen kibaszott patch halmokat kap mindenki a nyakába. Lásd még kernel és az indiai "kernelfejlesztők". Nem lesz sokkal jobb a maintenance budren. Ha meg jönnének, hogy átveszik/beszállnak ... hát, abból is lenne hiszti, hogy corporate takeover.... Szóval egyáltalán nem egyszerű ez az egész. És valójában ez inkább egy utolsó csepp jellegű probléma, nem új keletű dolog.

Más kérdés, hogy az OSS-nek a teljes kódtranszparencia a velejárója, ami nem feltétlen mindig hasznos, mint most mikor csak a sérülékenység ténye és kiváltásának módja lett publikálva a megoldás nem, de ez egy ilyen konstrukció.

Azért azt szeretném mondani, hogy ez most épp manyeyballz in action, csak hát mint minden nagy mondásról, erről is hamar kiderül, hogy ha tényleg elkezdődik, akkor azért nem úgy van az :)

Pont a múlt héten jött szembe velem az AI-generált vulnerability reportok problémaköréről (kapcsolódóan a CVE-rendszer jelenlegi állapotáról is) egy részletes bemutató blogbejegyzés (via HN), ami (szerintem megfontolandó) megoldási javaslatokat is tartalmaz.

A blogbejegyzés inkább az OSS projektekhez beküldött fals pozitív reportok nagy arányát és annak következményeit veszi jobban szemügyre, nem a posztban leírt valós(nak is tekinthető) bejelentéseket, de az egyik fő üzenet, hogy az OSS projekteken dolgozó maintainerek egyik fő problémája a kiégés. Ebből a szempontból pedig nem is olyan nagy a különbség a valós/nem valós bejelentések között, ha egyszerűen ömlik be a rengeteg AI-gyártotta találat.

Úgy gondolom, hogy ahogyan más területeken is nagy változásokat fog elindítani az AI jelenléte (teljesen mindegy, hogy "szofisztikált mintaillesztésként" vagy "mindentudó kvázi-istenségként" tekintünk rá), úgy a hibabejelentések, bug bounty-k és úgy általában az OSS projektek működése területén is gyökeres változásokra lesz szükség ahhoz, hogy ezek valamennyire működőképesek maradjanak.

Udv mindenkinek a csodalatos AI-korban! :popcorn:

#csaktudnikellahelyenkezelni

hat mar 20+ eve amikor meg reszt vettem az mplayer/ffmpeg fejleszteseben is voltak automatizalt hibakeresesek, csak nem AI-nak hivtak, hanem mindenfele fuzzer-nek. kb arrol szolt hogy random media fileba random atirt biteket-byteokat es megnezte elcrashel-e tole. ha igen ment automatice a bugreport. neha rank ontottek egy kamionnyit, foleg szinte sose hasznalt legacy formatumokkal kapcsolatban. nyilvan tele lehet b.szni minden codecet ellenorzesekkel, hogy kb bitenkent ellenorizzen le mindent, de ez erosen a performance rovasara menne, ami pont az ffmpeg erossege volt akkoriban a versenytarsakhoz (pl. gstreamer, avifile stb) kepest.

amugy meg a google miert nem javittatja is ki a hibat a csoda AI-javal es patchet kuld eleve? mindenkinek egyszerubb lenne...