←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 6 comments | 11 Nov 25 18:32 UTC | HN request time: 0.281s | source | bottom
Show context
ChrisMarshallNY ◴[11 Nov 25 20:33 UTC] No.45892464[source]▶
Looks like this was a security issue.

I don't consider a security issue to be a "standard bug." I need to look at it, and [maybe] fix it, regardless of who reported it.

But in my projects, I have gotten requests (sometimes, demands) that I change things like the published API (a general-purpose API), to optimize some niche functionality for one user.

I'll usually politely decline these, and respond with an explanation as to why, along with suggestions for them to add it, after the fact.

replies(1): >>45892555 #
1. cestith ◴[11 Nov 25 20:43 UTC] No.45892555[source]▶
It’s a security issue for a stream type almost nobody uses. It’s a little like saying your graphics program in 2025 is exploitable by a malformed PCX file, or your music player has a security bug only when playing an Impulse Tracker module.

Sure, triage it. It shouldn’t be publicly disclosed within a week of the report though, because the fix is still a relatively low priority.

replies(2): >>45892639 #>>45893307 #
2. jsnell ◴[11 Nov 25 20:49 UTC] No.45892639[source]▶
Security is adversarial. It doesn't matter whether the users intentionally use the vulnerable codec. What matters is whether an adversary can make the users to use it. Given the codec is compiled in by default on Ubuntu, and given that IIUC the bug would already be triggered by ffmpeg's file format probing, it seems pretty likely that the answer to that is yes.
replies(1): >>45893034 #
3. cestith ◴[11 Nov 25 21:20 UTC] No.45893034[source]▶
Yes, security is by definition adversarial. Thanks for the most basic lesson.

How are you getting ffmpeg to process a stream or file type different from the one you’re expecting? Most use cases of ffmpeg are against known input and known output types. If you’re just stuffing user-supplied files through your tools, then yes you have a different threat model.

replies(1): >>45893575 #
4. gowld ◴[11 Nov 25 21:45 UTC] No.45893307[source]▶
If no one uses the stream type, then not fixing the bug won't hurt.

The people who do use the stream type are at risk, and have been at risk all along. They need to stop using the stream type, or get the bug fixed, or triage the but as not exploitable.

5. jsnell ◴[11 Nov 25 22:10 UTC] No.45893575{3}[source]▶
> How are you getting ffmpeg to process a stream or file type different from the one you’re expecting?

... That is how ffmpeg works? With default settings it auto-detects the input codec from the bitstream, and the output codec from the extension. You have to go out of your way to force the input codec and disable the auto-detection, and I don't think most software using ffmpeg as a backend would force the user to manually do it, because users can't be trusted to know those details.

replies(1): >>45900442 #
6. cestith ◴[12 Nov 25 14:13 UTC] No.45900442{4}[source]▶
In the industry I think folks generally know what they’re feeding into it and what they’re wanting out of it. When there’s a handoff between companies the stream encoding, bitrate, and resolution are generally part of the project spec. Within a company, your teams should know what they’re feeding into a tool and it’s probably not some obscure LucasArts game codec.

If it’s a potential problem for home users, yeah, that’s an issue but it’s not every use of the tool.