Hacker News

If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.

On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.

There is a different dynamic between this and that.

Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance.

https://news.ycombinator.com/item?id=43140614

No. They tried that with coreutils and look what happened. More CVEs.

99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.

> If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up.

Isn't that what fuzzing and input validation is about? Most bugs presented in article suggest failures in the latter.

I don’t deal with ffmpeg or C/asm, but there are certainly some 4gl applications that a random patch may cause more problems than it solves. I imagine many researchers would be in that box.

I'm glad to see their sense of humour :-)

https://nitter.net/ffmpeg/status/2039115531744334180

Oh my god! They are so funny and memeable! gets RCE'd

In their defense, the "rewrite it in rust" crowd can be really grating.

Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.

I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.

I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).

I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.

Can't help laughing at a random ad hominem against John Carmack of all people, and about his opinion on a guy who is already widely regarded as an especially talented programmer.

I don't think that's fair. There's a lot of talent and grit behind ffmpeg. But for better or worse, getting the code to do what it's supposed to do requires a different mindset than getting it to not do anything else (i.e., to handle malicious inputs correctly).

The developers of ffmpeg are very good at the first thing and not very good at the second. But few people on this planet, if instructed to write a complex video format parser in C or assembly, can produce something that's secure on the first try. The main failing of the ffmpeg team is that they should have spent more time on architectural hardening and mitigations. Most other large projects of this type do.

So who is someone who's opinion is worth anything to you?

Except yourself, presumably, to me it almost seems nobody is perfect.

Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.

The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).

It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.

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

Ok but who is going to sift through it all to triage the good bits when you're working on something for free?

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

Who gives a shit about reputation when you're the only game in town?

There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.

That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins.

Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.

GStreamer doesn’t use ffmpeg’s pipeline at all. It implements a much more advanced directed graph with disconnect, connection and pad negotiation. You can dynamically swap out the entire filter graph during live playback with zero disruption. Swap feeds, outputs, effects… all at runtime.

ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines. You can use “switcher” components but the inputs are still static.

GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration.

GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.

GStreamer is not "just a different front end to ffmpeg". GStreamer is a pluggable media graph system.

"GStreamer" doesn't link against libav. The GStreamer plugin "gst-libav" links against libav. If you're not using the gst-libav, you're not using ffmpeg. I'd bet a relatively small amount of GStreamer use cases use gst-libav; I typically see people use e.g x264dec and x264enc (from the x264 plugin) to decode and encode media, or, for hardware encoding/decoding, the v4l2enc and v4l2dec elements (or elements from a SoC vendor's plug-in such as gst-rockchip). It also has its own non-libav elements to handle container formats, pixel format conversion, scaling, etc, which are more natural to use since they're part of the core gstreamer plug-in packages rather than gst-libav.

Usually it's Rewrite it in Rust, but both work I guess

I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...

Thus:

1. Code which processes untrusted input

2. Code written in unsafe languages like C or C++

3. Code that runs without a sandbox

So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.

Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.

Also, check https://opensource.apple.com/projects/

I genuinely didn't know about their OSS efforts, thanks!

Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development...

Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.

> the difference between a vulnerability and an exploit

is it the difference between a knife and a stab wound?

[dead]

Even that's revisionist.

Originally a zero-day exploit was one that was found by crackers on the first day of release of a software product. Like finding a licence crack for a new Microsoft program on the day it went on sale.

There used to be fierce competition to find such an exploit within those 24 hours, and great kudos for those who did.

Nowadays a zero-day can apparently be found years after release, which makes no sense.

Does "publication" refer to the software or to something documenting the existence of the bug? Because I thought zero-day meant the bug was exploited the same day the software containing the bug was released, but your phrasing sounds like if you exploit a bug before the maintainers know about it then it's a negative day.

I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.

A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.

The parent does argues it is safer to sandbox ffmpeg yes

What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks.

IMHO better C tooling would be a far better investment than rewriting in Rust.

unsafe never changes the semantics of anything. Unsafe gives you access to additional features, never changes the meaning of a feature.

Agreed, the option that sacrifices security in search of performance should be the more verbose one. There's a reason Rust doesn't have `safe {}` blocks and there's a reason it chose immutable-by-default semantics.

Ahah

But are the compiler+OS that runs the ffmpeg executable really a sandbox ?

Which is of course better than zero sandbox escapes.