Hacker News

On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through.

Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.

If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?

Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.

The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used.

If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.

Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap.

Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles

> the obvious alternative to ffmpeg

IIRC that is currently sandboxed ffmpeg.

Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!

I wouldn't call "nice find, care to help us fix that?" extremely hostile. It can be frustrating for open source projects that far more people want a pat on the back for the identification of a problem (be it security, performance, documentation, or anything else) than there are people who have the time and inclination to help resolve the issue (or ability and inclination to fund the project so it can more easily find help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.

https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw...

Security is the punch line for ffmpeg.

The guy running the twitter account is incompetent but the actual devs are a lot saner I think.

I agree it reflects poorly on them though

> … hostile to security researchers who report these issues.

Do you have an example?

One dude running an X account is not indicative of a community to be honest.

That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.

The majority of code in ffmpeg today isn't written by Fabrice, but also there's multiple axes that people view programming ability on. Some people can write software that will do things you couldn't imagine given the constraints. Some people can write software that is resilient against all malformed input. Sometimes these people are the same people, but frequently they're not.

One thing has nothing to do with the other.

Security vulnerabilities are less about programming ability and more about rigor.

Famous man whose last impactful work was decades ago and spent years on meta's sinking metaverse boat said so, so it must be true.

> nearly inexhaustible supply of LLM slop daily,

Actual well written vulnerability reports are not the same as slop.

AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.

Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.

Gstreamer is a multimedia framework where the user creates media DAGs by placing video/audio/multimedia elements such as demuxers, decoders etc in a pipeline. The framework then takes care of running the media pipeline and handles the data buffering etc.

Within the framework there are multitudes of plugin packages that contain said elements and many of them are built on top of ffmpeg.

Any multimedia project trying to support a large number of formats, whose usage in the wild differs by orders of magnitude, is going to have code of varying quality (although quality is not strictly correlated with usage: age and complexity are also big factors, among others). GStreamer puts plugins into different categories (-good, -bad, etc.) based on things like the maturity of the code, which helps you judge what risks you are taking. With FFmpeg it is harder to know which formats are more likely to have issues. Of course GStreamer can use FFmpeg, in which case you will also have all of FFmpeg's problems.

In both cases you are best off restricting things to what you actually use.

From what I understand gstreamer is more about building complex pipelines and plugins, ffmpeg is better at playing some obscure 20 year old video format extremely efficiently so you can watch it compiled for a potato.

Different cases really I think both are good.

GStreamer is just a different front end to ffmpeg.

ffmpeg's core functionality (encode, decode, streams, pipes, channels) are all implemented in `libav` which gstreamer links against.

Doesn't GStreamer mostly use ffmpeg plugins?

In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.

I haven't seen that acronym before, but my guess is that it's "Re-Implement In Rust", right?

What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc.

It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.

Hmm.. "shabby input" that makes software xyz fail is a problem in software xyz itself!

"Validate your inputs" is a common rule. Fuzzing is a thing. Both for good reasons (including security).

Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.

What?

https://github.com/apple

Speaking from firsthand experience: codec and other media processing libraries are some of the easiest software to find address leaks in.

(There are a number of reasons for this, not least being that C makes it very easy to ship partially initialized memory over the wire.)

Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.

No, I think it was since Code Red.

I understand why it's poorly understood. It's a snappy term, and people assume it means "bad" and nothing else because that's all you can get from the context. However, since most people also don't know the difference between a vulnerability and an exploit, they won't understand the definition of a zero-day when they read it.

But I'm still going to complain if a security vulnerability research company is using the term incorrectly in their own press copy. It makes them look amateurish.

(not op)

If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.

When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.

Isn't it safe to assume that no video file can escape the browser decoding sandbox?

It's 'safe to assume' it's not. It's emphatically not safe to assume any mitigation is perfect.

> Isn't it safe to assume that no video file can escape the browser decoding sandbox?

Why would that be safe to assume? If that were a reasonable assumption, you could just as well assume that it's safe to run ffmpeg.

One chained sandbox escape away from compromise.