Even if this isn't as big a deal as this [advertisement for a security company] seems, it is a reminder that every application you release does have a security hole somewhere, and a script kiddie can now find it 5 minutes after release for $2 in credit. If you're not red-teaming your code before release, hackers are doing it after.
Twenty One Zero-Days in FFmpeg
51–60 of 216 posts
Re: Twenty One Zero-Days in FFmpeg
#52Ffmpeg 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.…
[flagged]
Re: Twenty One Zero-Days in FFmpeg
#53Ffmpeg 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.…
Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?
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.
Re: Twenty One Zero-Days in FFmpeg
#54I've been using ffmpeg for a very long time, both personally and for services I've built. Fabrice Bellard is a genius, and the developers who have taken it so far have made the world measurably richer. But I can't think of a program more worthy of sandboxing when run with untrusted input than ffmpeg. It's a huge amount of C dealing with the most complicated video and audio codecs, which is notoriously impossible to g…
What do you mean "video file that I'm perfectly willing to play in my browser". Isn't it safe to assume that no video file can escape the browser decoding sandbox?
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.
Re: Twenty One Zero-Days in FFmpeg
#55Earlier quoted context omitted.
You would also need some sort of ASLR leak to make this exploitable
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.)
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.
Re: Twenty One Zero-Days in FFmpeg
#56Earlier quoted context omitted.
> 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.
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…
Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing.
And get hardware acceleration working...
Re: Twenty One Zero-Days in FFmpeg
#57I find difficult to know how serious the issue is, if it is even an issue. LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.
In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.
That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.
Re: Twenty One Zero-Days in FFmpeg
#58Earlier quoted context omitted.
It seems to have lost its meaning after getting popularized following Stuxnet coverage.
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 vulnerabili…
> the difference between a vulnerability and an exploit
is it the difference between a knife and a stab wound?
Re: Twenty One Zero-Days in FFmpeg
#59[dead]
Re: Twenty One Zero-Days in FFmpeg
#60Help me understand: depthfirst seems to be bigging up their “security agent” here, but is it not just prompt engineering + writing skill files? What goes into producing a “security agent” beyond this? Feels like they’re really gussying up a process that is ultimately just LLM usage