| ▲ | jacobgold 8 hours ago |
| 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 get completely right. But it's not actually that big of a problem. I run ffmpeg inside a VM or gVisor, and the end result is usually a video file that I'm perfectly willing to play in my browser, where it gets decoded in yet another sandbox because this shit is hard. |
|
| ▲ | Terr_ 3 hours ago | parent | next [-] |
| I glumly predict that copyright-holding companies wanting DRM, "trusted platforms", regulatory capture, etc. will drive some of the damage here. Secure sandboxing tends to mean opportunities to make unrestricted copies. |
|
| ▲ | Gehinnn 8 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | kjs3 5 hours ago | parent | next [-] | | 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. | |
| ▲ | thaumasiotes 8 hours ago | parent | prev [-] | | > 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. | | |
| ▲ | Denvercoder9 7 hours ago | parent | next [-] | | 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 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. | | |
| ▲ | lostglass 4 hours ago | parent [-] | | Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing. And get hardware acceleration working... |
| |
| ▲ | ttoinou 8 hours ago | parent | prev [-] | | The parent does argues it is safer to sandbox ffmpeg yes |
|
|
|
| ▲ | cyberax 7 hours ago | parent | prev [-] |
| But then you also often need hardware accelerators for encoding, so you need to use C again. |
