Posted by trollied 2 days ago
Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction.
Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".
You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)
Then why it has been enabled ? Asking for a friend. /s
Unless Apple, ffmpeg has a reason to enable old codecs. If you only need a subset: configure; make; make install
Because it's in the PDF spec, and you can't randomly disable parts of that.
I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used as an attack vector, e.g. via torrents.
Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
> VLC is pretty popular on windows, but ffmpeg?
> Is there any commonly used windows app that relies on it?
> I doubt it'd be worth one's time to write exploits for desktop Linux
How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.
https://signal.org/blog/cellebrite-vulnerabilities/
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
If Signal relies on ffmpeg to play videos instead of an externall app, i would say it is broken by design.
It's worth pointing out that many, many, many things use the libav* library family.
If the exploit chain involves the user downloading and opening a file, something like >99% of the time the next step already involves executable code (or Office macros), which makes any ffmpeg vuln completely useless.
It’s used for pretty much any platform you can upload video to. Some places far more competently than others.
Budget web host using outdated software getting hacked because they havent updated in 2 years isn't exactly all that interesting of a blog post even if the victim knows enough to figure out what happened.
It's used way, way more than you think.
And to the best of my knowledge, there has not been any in-the-wild exploit against Chrome through the handful of ffmpeg codecs they enable. Not even pwn2own type competitions either, as I recall.
D.V.L. sanm LucasArts SANM/SMUSH videoOn the one hand, this one Microsoft employee was probably in a bind and actually blocked by this bug. On some level, it's hard to blame them as an individual.
On the other hand, Microsoft has no leverage here and pays somewhere between a pittance and nothing for FFmpeg, while getting enormous use out of it. If they regularly donated with either money or patches, then there'd be no beef, but it's the expectation of getting something more for free while already getting so damn much for for zero cents that really grinds both mine and FFmpeg's gears.
That reminds me that I should probably throw some money at FFmpeg, if only to clear my conscience.
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+%40google...
And they have done large pushes in the past: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.
Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.
If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.
> because they use FFmpeg in a bunch of commercial products like Youtube and Chrome
I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.
Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.
> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.
It is up to you, the end user of the software to evaluate whether those terms, risks, and options are good enough for you. If not, don't use it. You have it completely backwards, and frankly, sound quite entitled.
Although perhaps my previous comment went a little too far. I think its fine to not fix issues as long as you publish them so that users can make an informed decision. Where i think it would be morally wrong is if a project pretends it fixes security issues but doesn't or if it tries to cover them up - insisting external reporters dont talk about them while also having no intention of fixing them.
Basically i think open source projects (like everyone) have a moral duty to be honest and not try and decieve people, regardless of what the license says.
I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.
I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.
Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations
If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.
> If you want the security issue to be fixed,
There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.
> willing to pay for them to fix.
Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.
If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.
But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.
Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.
My biggest gripe though is that ffmpeg does seem to value these sorts of reports highly. If i'm reading the timestamps right, they fixed this report within 1 day: https://github.com/FFmpeg/FFmpeg/commit/c41a70b6bb79707e1e3a...
How often do you get your bug reports fixed that fast? When i file bugs in open source projects it usually takes at least weeks if im lucky to get a response. People almost never respond within 1 day. I think that demonstrates how valuable ffmpeg views these reports.
If the report was a garbage report (like e.g. the ones the curl maintainer complains about) i'd have more sympathy, but clearly ffmpeg views this issue submission as valuable. The whole thing makes me think of choosing-beggars. They want the google report but also are trying to use social pressure to make google contribute even more.
If they didn't want google's reports that's one thing - just reject them, but both wanting them while also demanding more is scummy in my opinion. Either accept or reject them.
if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)
i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”
he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.
so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.
Edit: i guess its not even that, they are just bitter that they have to fix bugs in their own code??? Recieving vuln reports is a gift. If ffmpeg doesnt like it maybe google should just start practising full disclosure.
My hot-take: it's security theater drama. Burn-out maintainers on one side and wealthy corporate employees on the other.
The CVEs get reported, then big corps automated systems start flagging all use of ffmpeg, the big corp security software stops builds and removes it from dev laptops, then frustrated big corp engineers start harassing the volunteers and soon its not worth volunteering anymore, and the project dies, and there was never a real world impact.
The problem isn't that volunteer devs are harassed into work.
The problem is being harassed.
Whether or not you "care" or feel the need to do any work or accept responsibility, constant harassment will destroy anyone, even you.
You’d have to basically blacklist these orgs from all bug reports and maybe open it up to a select few known trusted senior resources that care more about their personal reputation within the community vs. corporate politics.
Sounds like a threat to me. ffmpeg is a tiny team and Google is a goliath. Not to mention Google has used their AI to spam the same threat, about 8 times in the last few months https://ffmpeg.org/security.html
There is a lot of historical context with this sort of thing that has lead to systems like this that has nothing to do with google.
Besides google did not sign an NDA, they aren't under any obligation to keep anything secret. 90 days is a courtesy. They are fully within their rights to just publish their findings immediately if they felt like it.
If you don't then your users should have the right know, so they can decide for themselves whether or not the risk is worth it.
Do you think that just because a project doesn't disclose something it goes away, or that if google can find the bug that much better funded groups like the NSA or malware vendors can't. Shoving things under the rug is the worst outcome.
Also, could you quote the request to sweep bugs under the rug?
The main ask seems to be "send patches" later in the thread
> currently have zero real-world impact
So better we not talk about them until someone bothers to write an exploit for it?
> the "researchers" didn't even bother to write a patch/fix
If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?
Not by classic bug reports.
I like to get such reports from the occasional fuzzer. Just ignore the CVE, it's a bug
A real gift would be to include a patch for it. Not just to run off into the sunset.
Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.
Vs “this is broken, you gave 90 days to fix it”
If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.
Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.
If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.
They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.
The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.
It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.
The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
[1] https://web.archive.org/web/20110315155125/https://multimedi...
Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.
One would expect Google to only use FFmpeg with vetted codecs and to either reject videos with codecs that have untrusted FFmpeg modules or to sandbox any such processing, both for increased safety and perhaps to occassionally find new malware "in the wild".
IIRC, his "LibAV" fork was malicious and his people lied a lot to the community ("ffmpeg is now deprecated!"). Ultimately, they failed, but I see a lot of their rhetoric and resentment in Kostya's post today.
And if you browse through the ffmpeg mailing list of that historic month https://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/ you'll find his name mostly attached to esoteric video game format patches and not in the big flamewar threads.
Actually - it looks like you can also see in that same month, his post of the first SMUSH codec implementation, that we're discussing in this thread. That's probably a bigger emotional factor than LibAV.
That's my point and also why I won't dig more. The author hasn't come to terms with his bad experience with ffmpeg, in LibAV or otherwise. Whatever the baggage is, it feels quite messy and heavy. It weighs down the article, with too much bitterness and resentment. That could work for self-therapy, less so for a credible account. As he confesses at the end:
> I wrote this post with an ulterior motive—I don’t want to feel shame when remembering that I took part in that project. So far though the more I hear about it the more disgusted I become.
Paid off how? Did they get more funding? More contributors?
On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain.
On the other hand, we have plenty of evidence that untrusted input validation bugs pose a very high risk to end users. So, for as long as this is their policy, FFmpeg code really should not be included in any system where security is at all important. Perhaps we need a "fundamentally unsafe for use" sticker for OSS projects taking this stance?
You can't pay for the software
>"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment"
The Google bug report is dated August 21: https://issuetracker.google.com/issues/440183164
There are FFmpeg commits apparently fixing the sanm codec problem within a day or so: https://github.com/FFmpeg/FFmpeg/commits/140fd653aed8cad774f...
Earlier, on August 20, there are FFmpeg fixes for other issues in the same codec apparently also found by Google (by fuzzing not AI?): https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...
I assume Google has several full time ffmpeg developers given how much they rely on it.
> We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix.
Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just because it isn't likely to be exploited doesn't mean it isn't there. While it'd be nice if Google contributed, if I had to choose between Google doing this and doing nothing, I'd choose this.
> Is it really the job of a volunteer working on hobby 1990s codec to care about Google's security issues? Or anyone's?
It isn't "Google's security issues", it's a FFmpeg security issue. The tone from this account is incredibly childish.
This exchange was what shocked me the most:
Person 1:
> If someone sends me cutekitten.mp4, but it is actually not an mp4 file, but a smush file using an obscure 1990s hobby codec, could the bug be exploited if I just run ffplay cutekitten.mp4?
FFmpeg:
> Is it the job of volunteers working on game codecs in their free time as a hobby to fix Google's AI generated bug reports?
Completely dodging the question.
It’s not that the vulnerability was found and reported, it’s that a trillion plus dollar organization that no doubt actively uses ffmpeg in a litany of spaces is punting the important work of fixing it to volunteers.
This is the same issue that we’re seeing over with XSLT in Chrome: they’re happy when they’re making money off the back of these projects but balk when it comes down to supporting them.
(Yes, everyone is aware Google contributes to open source. They’re still one of the most valuable companies to ever exist, there is almost no excuse for them getting away with this trade off)
But that would leave everyone else vulnerable, so they report it. Reporting real problems is a good thing.
Or, y'know, the project could balk at a trillion dollar company expecting them to do free work.
Cuts both ways.
https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING....
and then expect volunteers to provide them fixes.
This is part of Google’s standard disclosure policy: it gets disclosed within 90 days starting from confirmation+contact.
If ffmpeg didn’t want to fix it, they could’ve just let the CVE get opened.
> and then expect volunteers to provide them fixes.
Expect volunteers to provide everyone using the software with fixes.
Actually I think they are using correctly, you are suppose to post something to provoke the most reactions you can.
But getting back to the point, I agree, it is not really a problem if you actually verified your input before blindly running ffmpeg on it - like people are not just downloading random files and running ffmpeg on it are they?! You would think if you are rolling ffmpeg into production code you would know the ins and outs of it.
Anyways I feel for those open-source maintainers, they must have so deal with so much noise.
It reads to me like the only expectation is civility, not even necessarily an expectation of fixing it.
If Google can identify a vulnerability, what should they do? If they don't report it, they're effectively stockpiling weapons.
I'd wager that every usage of ffmpeg in Google infra is sandboxed, so calling this "Google's problem" seems silly to me.
Google can't be responsible for fixing everyone's sloppy C code.