What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?
Twenty One Zero-Days in FFmpeg
21–30 of 216 posts
Re: Twenty One Zero-Days in FFmpeg
#22Is there a timeline for each of these bugs? I wonder if these bugs had been reported to ffmpeg yet.
Re: Twenty One Zero-Days in FFmpeg
#23Ffmpeg 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.…
They're also extremely hostile to security researchers who report these issues.
Re: Twenty One Zero-Days in FFmpeg
#24> The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can…
You would also need some sort of ASLR leak to make this exploitable
Re: Twenty One Zero-Days in FFmpeg
#25Earlier quoted context omitted.
Browsers run it in a sandbox process together with allocator hardening. Most of the bugs then are just crashed of the sandbox Another option is WASM or WASM-style sandboxes if using another process is undesirable.
One chained sandbox escape away from compromise.
Which is of course better than zero sandbox escapes.
Re: Twenty One Zero-Days in FFmpeg
#26[flagged]
Re: Twenty One Zero-Days in FFmpeg
#27> At this point the corrupted free pointer is called, and control of the instruction pointer is ours. Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
The article glosses over this, but it looks like the next variable in the struct is conveniently the first parameter to the function, so you can run arbitrary code with system() or whatever. But, yeah, you would need some other exploit to defeat ASLR.
Re: Twenty One Zero-Days in FFmpeg
#28That's not what "zero-day" means.
Re: Twenty One Zero-Days in FFmpeg
#29Ffmpeg 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.…
ffmpeg is also rather popular and delivers a lot of functionality. Its unlikely that you don't have it installed.
Yes, there are security issues but quite a few are not ffmpeg itself related - the input is pretty shabby or at least not exactly easy to deal with!
Obviously, they could do with some assistance and I'm sure you and I will both dive in with equal zeal.
Re: Twenty One Zero-Days in FFmpeg
#30Ffmpeg 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]