11–20 of 216 posts
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.
Earlier quoted context omitted.
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? 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.
Earlier 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.
But are the compiler+OS that runs the ffmpeg executable really a sandbox ?
> 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…
If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
Is the future of defense-against-foreign-agents-on-my-codebase to subtly hide prompt injections into one’s codebase that would defeat agents to find security bugs ? If the attackers of ffmpeg need to be using such those authors’ services to find RCE in popular tools to attack, what the ffmpeg team needs to defeat attackers is to reduce efficiency of such tools depthfirst
LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.
I'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…
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 absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. I know that people do, and these people are taking unreasonable risks.
Earlier quoted context omitted.
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? 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.
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.