Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

Post reply on HN
Print view View original

171–180 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#171

Post by techscruggs »

The incentives structure is deeply broken in the field of Security Research. They are the middle management of the FOSS world. Celebrated for dumping more work on volunteers. The more urgent the work, the more they are celebrated. Acknowledging the realistic impact of issues or the pragmatic implications of an issue are at odds with their incentives.

It's hard not to see them as bottom feeders of the software industry and I wish we would starting treating them like pariah. Submit the PR or STFU.

Re: Twenty One Zero-Days in FFmpeg

#172

Post by dingaling »

perlgeek wrote: post #122
journal wrote: post #120

Earlier quoted context omitted.

Explain what it means along with your statement. Maybe I have the wrong definition too.

(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.

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.

Re: Twenty One Zero-Days in FFmpeg

#174

Post by hsbauauvhabzb »

dspillett wrote: post #151
loeg wrote: post #23

Earlier quoted context omitted.

They're also extremely hostile to security researchers who report these issues.

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…

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.

Re: Twenty One Zero-Days in FFmpeg

#175

Post by tptacek »

dspillett wrote: post #162
tptacek wrote: post #71

Earlier quoted context omitted.

Vulnerability researchers don't create the vulnerabilities they report. The vulnerabilities exist whether or not they're reported by "clout chasers".

There is a difference between a proper vulnerability researcher and a clout chaser calling themselves a vulnerability researcher. Research for a start, to assess the problem to see if it is genuine and if so if there are significant mitigating factors (by default or that can be implemented), and checking if it hasn't already been reported, instead of just copypasting some LLM output with minimal review. And to many c…

No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.

Re: Twenty One Zero-Days in FFmpeg

#176

Post by sph »

LegionMammal978 wrote: post #147
simjnd wrote: post #127

Earlier quoted context omitted.

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

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 u…

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.

Re: Twenty One Zero-Days in FFmpeg

#177

Post by mort96 »

hugmynutus wrote: post #77
nerdsniper wrote: post #33

Earlier quoted context omitted.

Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?

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.

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.

Re: Twenty One Zero-Days in FFmpeg

#178

Post by mr_toad »

zerobees wrote: post #19

Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…

The difficulty in exploiting ffmpeg is getting anyone to use it on your input. Sure, you might pwn a few people, but is it worth the effort?

Re: Twenty One Zero-Days in FFmpeg

#179

Post by mort96 »

Thev00d00 wrote: post #116
rcbdev wrote: post #105

Earlier quoted context omitted.

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

I wouldn't go so far as efforts, so much as legally required publication of 3rd party code they use, or open wrappers to their proprietary libraries

Or .. their operating system and kernels

Re: Twenty One Zero-Days in FFmpeg

#180

Post by mort96 »

Sesse__ wrote: post #119
harrall wrote: post #86

Earlier quoted context omitted.

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 “switch…

> ffmpeg and other media frameworks (Windows Media Foundation, Apple’s AVFramwork) only support static pipelines. FFmpeg doesn't do “pipelines”. It's a library, not a framework.

It's also a command line tool, where you can design (limited) media graphs: sources, sinks, filters, encoders, decoders, muxers, demuxers. You don't express it as directly as gst-launch's pipeline syntax, but it's very much a pipeline.
Post reply on HN