7 ms·

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 w

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-fixes.html 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.

mr_toad 4mo ago
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?
loeg 4mo ago
They're also extremely hostile to security researchers who report these issues.
- insanitybit 4mo ago
  https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkwEjCgUtFgPYFoX2MRw https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw... Security is the punch line for ffmpeg.
  - hootz 4mo ago
    Oh my god! They are so funny and memeable! gets RCE'd
  - grahamjperrin 4mo ago
    I'm glad to see their sense of humour :-) https://nitter.net/ffmpeg/status/2039115531744334180 https://nitter.net/ffmpeg/status/2039115531744334180
    - KPGv2 4mo ago
      > Assembly is a human readable version of machine code. It's exactly the same. goddamn, and this is a project that prides itself on having had-written assembly in it
      - breppp 4mo ago
        There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
        rcbdev 4mo ago
        In some circles, High Level Assembly (HLA) is lovingly called "Mainframe Assembly".
  - KPGv2 4mo ago
    Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
    - hdgvhicv 4mo ago
      Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email” I couldn’t believe they had fallen for an April fools so hard.
  - stackghost 4mo ago
    In their defense, the "rewrite it in rust" crowd can be really grating.
- grahamjperrin 4mo ago
  > … hostile to security researchers who report these issues. Do you have an example?
  - naturalmovement 4mo ago
    I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).
  - lukaslalinsky 4mo ago
    I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
    - krageon 4mo ago
      I've run a bug bounty program for a relatively large corporation and you are exactly right. It's worse in open source, because none of the developers owe a researcher their time. At least in a bug bounty program you've communicated willingness both ways already
- duped 4mo ago
  One dude running an X account is not indicative of a community to be honest. That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.
  - boomlinde 4mo ago
    I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.
    - duped 4mo ago
      The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.
      - boomlinde 4mo ago
        If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
- lkt 4mo ago
  The guy running the twitter account is incompetent but the actual devs are a lot saner I think. I agree it reflects poorly on them though
  - deleted 4mo ago
    [deleted]
- dspillett 4mo ago
  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 help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.
  - hsbauauvhabzb 4mo ago
    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.
gerdesj 4mo ago
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.
- RetroTechie 4mo ago
  Hmm.. "shabby input" that makes software xyz fail is a problem in software xyz itself! "Validate your inputs" is a common rule. Fuzzing is a thing. Both for good reasons (including security).
naturalmovement 4mo ago
[flagged]
- LeoPanthera 4mo ago
  You should rethink this kind of casual racism.
- bawolff 4mo ago
  > nearly inexhaustible supply of LLM slop daily, Actual well written vulnerability reports are not the same as slop. AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.
  - naturalmovement 4mo ago
    > AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ok but who is going to sift through it all to triage the good bits when you're working on something for free? > Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation Who gives a shit about reputation when you're the only game in town? There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
    - bawolff 4mo ago
      > Ok but who is going to sift through it all to triage the good bits when you're working on something for free? Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs. > Who gives a shit about reputation when you're the only game in town? Its up to the maintainers whether they care or not. It depends on what they value. Ultimately if maintainers make decisions that are at odds with what their userbase want, someone eventually forks and people vote with their feet.
nerdsniper 4mo ago
Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?
- ranger_danger 4mo ago
  In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.
- WD-42 4mo ago
  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.
  - hackernudes 4mo ago
    That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins. Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
- wmf 4mo ago
  Doesn't GStreamer mostly use ffmpeg plugins?
- hugmynutus 4mo ago
  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.
  - harrall 4mo ago
    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 “switcher” components but the inputs are still static. GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration. GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.
deleted 4mo ago
[deleted]
mkagenius 4mo ago
[flagged]
- literallyroy 4mo ago
  Pretty bad astroturfing
oinoom 4mo ago
Funny, John Carmack was just admiring the creator of ffmpeg the other day for being a better programmer. https://x.com/id_aa_carmack/status/2064095424420487226?s=46 https://x.com/id_aa_carmack/status/2064095424420487226?s=46
- tptacek 4mo ago
  One thing has nothing to do with the other.
  - deleted 4mo ago
    [deleted]
- wavemode 4mo ago
  Security vulnerabilities are less about programming ability and more about rigor.
- pibaker 4mo ago
  [flagged]
  - endofreach 4mo ago
    So who is someone who's opinion is worth anything to you? Except yourself, presumably, to me it almost seems nobody is perfect.
    - pibaker 4mo ago
      On this subject I'd at minimum expect someone with experience in security. Not someone most famously known for making toys that run on computers.
      - bravoetch 4mo ago
        I've seen a lot of things written about Carmack over the last 30+ years, not one comment this casually dismissive until today.
anon-3988 4mo ago
[flagged]
cubefox 4mo ago
> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.
- defrost 4mo ago
  What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc. It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
  - mr_toad 4mo ago
    Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.
  - ReactiveJelly 4mo ago
    I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... Thus: 1. Code which processes untrusted input 2. Code written in unsafe languages like C or C++ 3. Code that runs without a sandbox So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
    - defrost 4mo ago
      I completely agree, with regard for the GP's point about Android TV's with onboard ffmpeg libraries and Addon Apps that call on said libraries (or pull in their own) .. Cheap arse low resource TVs should either include some form of sandboxing OR the entire device should be treated as a "can fall over" sandbox .. well isolated from any household LAN of consequence, etc. It seems unlikely that BoxStore Brand Android TVs will be well designed with an eye to security so <shrug> they're an exercise for home net admin masochists and/or an opportunity to market sensible easy to use IoT age routers that come preconfigured to handle bad-device(s).
bitwize 4mo ago
Time to RIIR, then?
- anonymousiam 4mo ago
  I haven't seen that acronym before, but my guess is that it's "Re-Implement In Rust", right?
  - erk__ 4mo ago
    Usually it's Rewrite it in Rust, but both work I guess
endofreach 4mo ago
Of course. Everybody knows to rather use the obvious alternative to ffmpeg!
- dspillett 4mo ago
  > the obvious alternative to ffmpeg IIRC that is currently sandboxed ffmpeg. Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!
teravor 4mo ago
while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.
- BoingBoomTschak 4mo ago
  Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap. Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles
simjnd 4mo ago
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.
- codedokode 4mo ago
  If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
  - cryo32 4mo ago
    No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
    - codedokode 4mo ago
      In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
      - uecker 4mo ago
        Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
        codedokode 4mo ago
        To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
imjonse 4mo ago
The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible? They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.
- lionkor 4mo ago
  Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.
jstanley 4mo ago
Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it. Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?
- defrost 4mo ago
  Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.
- m4rtink 4mo ago
  Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?
  - TD-Linux 4mo ago
    Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.
- franga2000 4mo ago
  The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used. If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.
hahn-kev 4mo ago
I use it in WASM on the client and call it a day. It works for our use case, but obviously not most.
preg_match 4mo ago
FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain. It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.
- nulltype 4mo ago
  For the implemented formats, wuffs is safer and also often faster: https://github.com/google/wuffs https://github.com/google/wuffs

mr_toad 4mo ago

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?

loeg 4mo ago

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

insanitybit 4mo ago
https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkwEjCgUtFgPYFoX2MRw https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw... Security is the punch line for ffmpeg.
- hootz 4mo ago
  Oh my god! They are so funny and memeable! gets RCE'd
- grahamjperrin 4mo ago
  I'm glad to see their sense of humour :-) https://nitter.net/ffmpeg/status/2039115531744334180 https://nitter.net/ffmpeg/status/2039115531744334180
  - KPGv2 4mo ago
    > Assembly is a human readable version of machine code. It's exactly the same. goddamn, and this is a project that prides itself on having had-written assembly in it
    - breppp 4mo ago
      There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
      - rcbdev 4mo ago
        In some circles, High Level Assembly (HLA) is lovingly called "Mainframe Assembly".
- KPGv2 4mo ago
  Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
  - hdgvhicv 4mo ago
    Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email” I couldn’t believe they had fallen for an April fools so hard.
- stackghost 4mo ago
  In their defense, the "rewrite it in rust" crowd can be really grating.
grahamjperrin 4mo ago
> … hostile to security researchers who report these issues. Do you have an example?
- naturalmovement 4mo ago
  I have numerous examples of security researchers being hostile and impossible to work with (but cannot share them unfortunately).
- lukaslalinsky 4mo ago
  I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
  - krageon 4mo ago
    I've run a bug bounty program for a relatively large corporation and you are exactly right. It's worse in open source, because none of the developers owe a researcher their time. At least in a bug bounty program you've communicated willingness both ways already
duped 4mo ago
One dude running an X account is not indicative of a community to be honest. That said, that dude has a point. "Researchers" chasing clout with their names attached to CVEs is kind of ridiculous. Half these CVEs are missing bounds checks that can be fixed with a patch in as much effort as writing up the blog post announcing that there was a missing bounds check.
- boomlinde 4mo ago
  I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.
  - duped 4mo ago
    The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.
    - boomlinde 4mo ago
      If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
lkt 4mo ago
The guy running the twitter account is incompetent but the actual devs are a lot saner I think. I agree it reflects poorly on them though
- deleted 4mo ago
  [deleted]
dspillett 4mo ago
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 help if needed). The use of LLM based tools apparently making that pat on the back easier to attain is going to exacerbate that problem for a while at least.
- hsbauauvhabzb 4mo ago
  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.

gerdesj 4mo ago

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.

RetroTechie 4mo ago
Hmm.. "shabby input" that makes software xyz fail is a problem in software xyz itself! "Validate your inputs" is a common rule. Fuzzing is a thing. Both for good reasons (including security).

naturalmovement 4mo ago

[flagged]

LeoPanthera 4mo ago
You should rethink this kind of casual racism.
bawolff 4mo ago
> nearly inexhaustible supply of LLM slop daily, Actual well written vulnerability reports are not the same as slop. AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.
- naturalmovement 4mo ago
  > AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ok but who is going to sift through it all to triage the good bits when you're working on something for free? > Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation Who gives a shit about reputation when you're the only game in town? There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
  - bawolff 4mo ago
    > Ok but who is going to sift through it all to triage the good bits when you're working on something for free? Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs. > Who gives a shit about reputation when you're the only game in town? Its up to the maintainers whether they care or not. It depends on what they value. Ultimately if maintainers make decisions that are at odds with what their userbase want, someone eventually forks and people vote with their feet.

nerdsniper 4mo ago

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

ranger_danger 4mo ago
In my experience it's mainly run by very grumpy and opinionated Europeans who take pride in having bugs old enough to drink.
WD-42 4mo ago
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.
- hackernudes 4mo ago
  That's not really true. Ffmpeg is a Swiss army knife for anything related to digital multimedia (old and new). It is broken into a few libraries but doesn't really have plugins. Gstreamer has a different model, chaining together plugins. Lots of overlap, but I think Gstreamer only has real traction because some silicon vendors use it.
wmf 4mo ago
Doesn't GStreamer mostly use ffmpeg plugins?
hugmynutus 4mo ago
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.
- harrall 4mo ago
  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 “switcher” components but the inputs are still static. GStreamer is extremely special. The only thing that comes close was Microsoft’s DirectShow, which has since been replaced with Media Foundation which can’t do it. And while DirectShow did support it, it was fragile because many 3rd party filters did not support dynamic configuration. GStreamer does use ffmpeg, but it just wraps the core encoder/decoder/filter code and discards the streams/graph/pipe part of ffmpeg.

deleted 4mo ago

[deleted]

mkagenius 4mo ago

[flagged]

literallyroy 4mo ago
Pretty bad astroturfing

oinoom 4mo ago

Funny, John Carmack was just admiring the creator of ffmpeg the other day for being a better programmer. https://x.com/id_aa_carmack/status/2064095424420487226?s=46 https://x.com/id_aa_carmack/status/2064095424420487226?s=46

tptacek 4mo ago
One thing has nothing to do with the other.
- deleted 4mo ago
  [deleted]
wavemode 4mo ago
Security vulnerabilities are less about programming ability and more about rigor.
pibaker 4mo ago
[flagged]
- endofreach 4mo ago
  So who is someone who's opinion is worth anything to you? Except yourself, presumably, to me it almost seems nobody is perfect.
  - pibaker 4mo ago
    On this subject I'd at minimum expect someone with experience in security. Not someone most famously known for making toys that run on computers.
    - bravoetch 4mo ago
      I've seen a lot of things written about Carmack over the last 30+ years, not one comment this casually dismissive until today.

anon-3988 4mo ago

[flagged]

cubefox 4mo ago

> Ffmpeg is absolutely not something you should be running outside of a sandbox if you're touching any untrusted or user-supplied content. You would change your opinion quickly if your browser, apps and TV suddenly stopped supporting videos due to relying on FFmpeg.

defrost 4mo ago
What prevents running a data stream in, transcoded data out sandbox with no access to unlimited resources, system files, system stacks, etc. It's okay for a sandbox to fall over due to bad inputs and poor memory security if it can just be restarted and move onto other streams.
- mr_toad 4mo ago
  Most of them require hardware acceleration from the CPU or GPU and that can potentially be exploited to escape the sandbox. GPUs in particular are difficult to sandbox.
- ReactiveJelly 4mo ago
  I think Chromium already does sandbox ffmpeg in the renderer process because of their "Rule of Two": https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s... Thus: 1. Code which processes untrusted input 2. Code written in unsafe languages like C or C++ 3. Code that runs without a sandbox So ffmpeg should be sandboxed, same as the network code and GPU process are sandboxed.
  - defrost 4mo ago
    I completely agree, with regard for the GP's point about Android TV's with onboard ffmpeg libraries and Addon Apps that call on said libraries (or pull in their own) .. Cheap arse low resource TVs should either include some form of sandboxing OR the entire device should be treated as a "can fall over" sandbox .. well isolated from any household LAN of consequence, etc. It seems unlikely that BoxStore Brand Android TVs will be well designed with an eye to security so <shrug> they're an exercise for home net admin masochists and/or an opportunity to market sensible easy to use IoT age routers that come preconfigured to handle bad-device(s).

bitwize 4mo ago

Time to RIIR, then?

anonymousiam 4mo ago
I haven't seen that acronym before, but my guess is that it's "Re-Implement In Rust", right?
- erk__ 4mo ago
  Usually it's Rewrite it in Rust, but both work I guess

endofreach 4mo ago

Of course. Everybody knows to rather use the obvious alternative to ffmpeg!

dspillett 4mo ago
> the obvious alternative to ffmpeg IIRC that is currently sandboxed ffmpeg. Until the people going on about making an equivalent in pure rust being automatically much safer, stop talking about it and actually get on with making it, of course!

teravor 4mo ago

while sandboxing ffmpeg directly isn't difficult, unfortunately with something like MPV/VLC that uses ffmpeg it's more challenging. until recently (virtio gpu native context) it wasn't even possible to sandbox a video player without losing all hardware acceleration. at least not from the outside, they could always try to sequester ffmpeg and seccomp it to hell like chromium.

BoingBoomTschak 4mo ago
Sandboxing not only OS access but also hardware access feels almost impossible to be honest. At least not via user-friendly exec based stuff like bwrap. Personally, I still try to contain them a bit: https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles https://git.sr.ht/~q3cpma/ezbwrap/tree/master/item/profiles

simjnd 4mo ago

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.

codedokode 4mo ago
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
- cryo32 4mo ago
  No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
  - codedokode 4mo ago
    In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
    - uecker 4mo ago
      Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
      - codedokode 4mo ago
        To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.

imjonse 4mo ago

The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible? They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.

lionkor 4mo ago
Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.

jstanley 4mo ago

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it. Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?

defrost 4mo ago
Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.
m4rtink 4mo ago
Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?
- TD-Linux 4mo ago
  Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.
franga2000 4mo ago
The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used. If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.

hahn-kev 4mo ago

I use it in WASM on the client and call it a day. It works for our use case, but obviously not most.

preg_match 4mo ago

FFmpeg is extremely complex software, with an extreme (and necessary) focus on performance, that exists in an extremely complex domain. It’s not just FFmpeg. Apple has had more vulnerabilities in image and video decoders than I can count. That stuff is just very hard, and FFmpeg is doing more than anyone else.

nulltype 4mo ago
For the implemented formats, wuffs is safer and also often faster: https://github.com/google/wuffs https://github.com/google/wuffs