Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems.

ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also need to deal with creating thumbnails of images and document.

And personally, I'd go a step further and keep the servers that deal with user-generated files in more than accepting and serving them in their own, heavily locked down VLAN (or Security Group if you're on AWS).

That's not a dumbass criticism of any of these projects mentioned by the way. Security is hard, especially when dealing with binary formats that have inherited a lot of sometimes questionably reverse engineered garbage. It's wise to recognize this before getting fucked over like 4chan was.

[1] https://ffmpeg.org/security.html




if you're worried about arbitrary code exec from an ffmpeg vuln, docker is not a sufficient security boundary.


What is?


I've build a custom thumbnail/metadata extraction toolkit based on libavcodec/libavformat that runs the decoding in seccomp's strict mode and communicates the results through a linear RGB stdout stream. Works pretty well and has low overhead and complexity.

Full transcoding would be a bit more complex, but assuming decoding is done in software, I think that should also be possible.


Full virtualization. Docker implies a shared kernel attack surface, that's what you want to avoid.


Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary


It's layers. Docker is better than nothing, but a VM is better still, and even better is docker on a dedicated VM on dedicated hardware on a dedicated network segment.


That's sacrificing an awful lot of latency cost for each transcode job though.


Firecracker says it can start a VM in 125 ms, for most transcode jobs that seems like it'd be a trivial cost.


Each job sends a provisioning ticket to a thermal printer. 1 business day turnaround, unless we need to order more servers


To make a bit of a strawman of what you are saying even better still would be an unplugged power cable as a turned off machine is (mostly) unhackable.

To be more serious seurity is often in conflict with simplicity, efficiency, usability, and many other good things.

A baseline level of security (and avoidance of insecurities) should be expected everywhere, docker allows many places to easily reach it and is often a good enough tradeoff for many realities.


that escalated quickly.

but I agree.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: