What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.
> 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?
There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
Because it burns out developers and ruins the project. Its like how the treatment can be worse than the disease in medicine.
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.
My point of view is that the unpaid ffmpeg maintainers should stop playing along with the corporate "security researchers" and not prioritize a bug over everything else simply because it's a CVE. In this case, the "high priority CVE" is from a reverse-engineered codec a hobbyist wrote to decode video from 1990s LucasArts video games. I think it's unreasonable to expect the maintainers to drop everything to fix a bug in a codec that most people will never use. If the trillion-dollar companies sending AI-generated CVE reports care so strongly about getting them fixed ASAP, they should really be fixing them themselves.
They're not being harrassed. You're basically saying that because FFmpeg doesn't have enough resources to fix all the security vulnerabilities, we should fix it by pretending like there are none.
My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to start fixing things themselves, contract someone to do so, or stop using ffmpeg due to all the scary CVEs getting flagged in whatever bullshit security compliance standard they use.
It would not stop the harassment at all. These reports are effectively free for the originating organization to write using AI - and some low level junior looking for promotion within said org will be highly motivated to pump those metrics up come review time.
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.
> This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-11-20 [https://issuetracker.google.com/issues/436510153]
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
Google is hardly the first people to come up with the notion of responsible disclosure. Whether you agree or not with the practise, the goal is to balance the needs of the maintainer with the needs of consumers. In practise such practises have massively boosted security of computer systems.
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.
What absolute nonsense. There's a gulf of difference between "there's no way 500+ codecs contributed mostly by unpaid hobbyists is robust to hostile input" and "here's working exploit code."
Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.
To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).
Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?
There's this weird "damned if you do, damned if you don't" situation on social media where people try to help and get reamed for not doing enough. Taylor Swift donated $500k to charity and people complaining she didn't round up to a million. After all, she can afford it.
But she ends up getting more criticism than the billionaire who donates nothing. Seems unfair but I guess it's human nature.
Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
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.
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
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
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.
FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?
> 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).
I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)
Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still.
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.
In fairness, i dont think the majority of actual exploits used in the wild get writeups.
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.
Yes, I’m quite familiar with that. Chrome is why I added the “generally” qualifier.
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.
I guess I'm confused - are you trying to imply the lack of a thorough, publicly reported successful exploit (or us just not casually giving you one that you care about) means that we're all released from the responsibility of taking potential exploits seriously?
Depends if any important websites are re-compressing user-uploaded videos. If there's a website converting user-uploaded gifs to mp4 to save on bandwidth or something, I wouldn't be surprised if they used ffmpeg to do it.
Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.
It had too much unnecessary metadata yes, but case insensitivity is always the wrong way to do stuff in programming (e.g. case insensitive file system paths). The only reason you'd want it is for real-world stuff like person names and addresses etc. There's no reason you'd mix the case of your CSS classes anyway, and if you want that, why not also automatically match camelCase with snake_case with kebab-case?
Well, to parsing it for machines yes, but for humans writing and reading it they are helpful. For example, if you have
<p> foo
<p> bar
and change it to
<div> foo
<div> bar
suddenly you've got a syntax error (or some quirks mode rendering with nested divs).
The "redundancy" of closing the tags acts basically like a checksum protecting against the "background radiation" of human editing.
And if you're writing raw HTML without an editor that can autocomplete the closing tags then you're doing it wrong anyway.
Yes that used to be common before and yes it's a useful backwards compatibility / newbie friendly feature for the language, but that doesn't mean you should use it if you know what you're doing.
It sounds like you're headed towards XHTML. The rise and fall of XHTML is well documented and you can binge the whole thing if you're so inclined.
But my summarization is that the reason it doesn't work is that strict document specs are too strict for humans. And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.
The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it.
> And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.
Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of my comment, or perhaps you replied to the wrong guy?
I'm a stickling pedant for HTML validity, but close tags on <p> and <li> are optional by spec. Close tags for <br>, <img>, and <hr> are prohibited. XML-like self-closing trailing slashes explicitly have no meaning in XML.
Close tags for <script> are required. But if people start treating it like XML, they write <script src="…" />. But that fails, because the script element requires closure, and that slash has no meaning in XML.
I think validity matters, but you have to measure validity according to the actual spec, not what you wish it was, or should have been. There's no substitute for actually knowing the real rules.
Are you misunderstanding on purpose? I am aware they are optional. I am arguing that there is no reason to omit them from your HTML. Whitespace is (mostly) optional in C, does that mean it's a good idea to omit it from your programs? Of course a br tag needs no closing tag because there is no content inside it. How exactly is that an argument for omitting the closing p tag? The XML standard has no relevance to the current discussion because I'm not arguing for "starting to treat it like XML".
I'm beginning to think I'm misunderstanding, but it's not on purpose.
Including closing tags as a general rule might make readers think that they can rely on their presence. Also, in some cases they are prohibited. So you can't achieve a simple evenly applied rule anyway.
Well, just because something is allowed by the syntax does not mean it's a good idea, that's why pretty much every language has linters.
And I do think there's an evenly applied rule, namely: always explicitly close all non-void elements. There are only 14 void elements anyway, so it's not too much to expect readers to know them. In your own words "there's no substitute for actually knowing the real rules".
I mean, your approach requires memorizing for which 15 elements the closing tag can be omitted anyway (otherwise you'll mentally parse the document wrong (i.e. thinking a br tag needs to be closed is equally likely as thinking p tags can be nested)).
The risk that somebody might be expecting a closing tag for an hr element seems minuscule and is a small price to pay for conveniences such as (as I explained above) being able to find and replace a p tag or a li tag to a div tag.
I don't believe there are any contexts where <li> is valid that <div> would also be valid.
I'm not opposed to closing <li> tags as a general a general practice. But I don't think it provides as much benefit as you're implying. Valid HTML has a number of special rules like this. Like different content parsing rules for <textarea> and <script>. Like "foreign content".
If you try to write lint-passing HTML in the hopes that you could change <li> to <div> easily, you still have to contend with the fact that such a change cannot be valid, except possibly as a direct descendant of <template>.
Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.
IMO, all of those make logical sense. If you’re inserting a line break or literal line, it can be thought of as a 1-dimensional object, which cannot enclose anything. If you want another one, insert another one.
In contrast, paragraphs and lists do enclose content, so IMO they should have clear delineations - if nothing else, to make visually understanding the code more clear.
I’m also sure that someone will now reference another HTML attribute I didn’t think about that breaks my analogy.
Sometimes you double click and it opens everything just fine and silently corrupts and changes and drops data without warning or notification and gives you no way to prevent it.
The day I found that Intellij has a built in CSV tabular editor and viewer was the best day.
> 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?