It sounds like about the right level of effort required to maintain something developed by Fabrice Bellard.
FFmpeg and a thousand fixes
81–90 of 150 posts
Re: FFmpeg and a thousand fixes
#82Earlier quoted context omitted.
I'm not proud of this legacy code, but... it exists because it was a real world issue that would cripple a conversion server in production envs when fed certain files with timing/syncing errors as part of an automated upload and conversion process. When it would crash it would consume 100% of the cores and eat up enough RAM to force swap. This cron has been keeping ffmpeg in check for over 4 years (not 6, whoopsie) i…
Tell the truth, it's only been 4 years.
damn... should have checked svn logs first, busted.
r8645 | * | 2010-02-09 18:11:35 -0500 (Tue, 09 Feb 2010) | 2 lines
Re: FFmpeg and a thousand fixes
#83Earlier quoted context omitted.
Yeah definitely. Really there is a gross violation of the principle of least privilege here. A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Given that there are apparently thousands of bugs in the video parsing code, it seems like a no-brainer.…
This bit made me gasp a bit: "[...] all it needs [...]" Off the top of my head: > video output Meaning: RW access to /dev/dri/cardX on desktop. In an embedded system, replace that with /dev/fbX. In most cases, we're rendering to GL buffers. Do you trust the GL drivers to be completely bug free? (Hint: from some embedded drivers I've dealt with I find it remarkable they work at all.) > doesn't need to [...] open netwo…
The network stuff should be replaceable with a file descriptor and a dead simple app-specific protocol. Just like Chrome has a little protocol for communicating between the UI and renderer processes.
I think you could also provide less than full access to the graphics driver. You could have a file descriptor or shared memory protocol, with the sandboxed process outputting video frames, and the parent process actually communicating with the driver.
In addition to being more secure, it's also better software architecture. VLC/ffmpeg are already way more modular than say the Microsoft equivalents.
Re: FFmpeg and a thousand fixes
#84Earlier quoted context omitted.
Yeah definitely. Really there is a gross violation of the principle of least privilege here. A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Given that there are apparently thousands of bugs in the video parsing code, it seems like a no-brainer.…
> A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Not sure if serious or sarcasm, to be honest, since this seems very far from what we see. A media player is not simple to sandbox, (as the MacOS X sandbox showed us for example), because: - you n…
I'm talking about a multiprocess architecture like Chrome.
http://www.chromium.org/developers/design-documents/multi-pr...
The entire app isn't sandboxed -- just the code that does video parsing, i.e. with the thousands of bugs and hundreds of remote code execution exploits (!).
See my other comment on this topic. ffmpeg is already very modular, and used in many video players (user interfaces), so this separation is more than natural -- it already exists in the codebase.
BTW, some people seem to be unfamiliar with the multiprocess/Unix design approach (usually people with a Windows background, which I came from as well). I recommend http://www.catb.org/esr/writings/taoup/ for a great intro to this design philosophy.
Re: FFmpeg and a thousand fixes
#85Earlier quoted context omitted.
A good entry on this, for those interested: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
That is written by the FFmpeg side. Do you have a complementary view?
The mpv developers have published an overview of the situation from their independent perspective which (FWIW) is very accurate from my vantage point as well: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav
Re: FFmpeg and a thousand fixes
#86Earlier quoted context omitted.
> A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Not sure if serious or sarcasm, to be honest, since this seems very far from what we see. A media player is not simple to sandbox, (as the MacOS X sandbox showed us for example), because: - you n…
I'm talking about a multiprocess architecture like Chrome. http://www.chromium.org/developers/design-documents/multi-pr... The entire app isn't sandboxed -- just the code that does video parsing, i.e. with the thousands of bugs and hundreds of remote code execution exploits (!). See my other comment on this topic. ffmpeg is already very modular, and used in many video players (user interfaces), so this separation is…
> The entire app isn't sandboxed -- just the code that does video parsing, i.e. with the thousands of bugs and hundreds of remote code execution exploits (!).
The exploits are usually on the protocol (access) level, the demuxer (format) level but also the decoder level.
While in theory the first 2 are what you call parsing, many security issues appear also at the decoder level.
And if you want to split the video decoder from the rendering, you need to introduce an additional memcpy (or two) of full decoded frames, which has an important impact.
I agree it would be nice to try, with a correct, separated processes architecture, but it means changing also a bit the usual architecture, where there is a direct-rendering between the decoder and the output.
Re: FFmpeg and a thousand fixes
#87It is interesting that YouTube isn't mentioned in this blogpost, despite there being good evidence that ffmpeg has been used there[1]. The fuzz testing they mention is based around constructing malformed (or at least "exotic") input files and then monitoring for failures... ie simulating exactly the kind of attack someone might use against YouTube's transcoding infrastructure. [1] http://multimedia.cx/eggs/googles-yo…
I'm not proud of this legacy code, but... it exists because it was a real world issue that would cripple a conversion server in production envs when fed certain files with timing/syncing errors as part of an automated upload and conversion process. When it would crash it would consume 100% of the cores and eat up enough RAM to force swap. This cron has been keeping ffmpeg in check for over 4 years (not 6, whoopsie) i…
Did you really write that comment on line 31 four years ago? :)
Re: FFmpeg and a thousand fixes
#88The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.
Really breaking new ground here. What should FFmpeg have been written in? I can think of a few candidates, but I think they share a number of those "wonders".
Ada would have been a good one, and mature enough. :)
Re: FFmpeg and a thousand fixes
#89Earlier quoted context omitted.
programmers are people
Programmers are people, but how many python programmers run into double-free bugs? Language has a lot to do with what sort of issues programmers will have to tackle.
At the same time, how many video players have been written in pure python? Assuming the number is non-zero, how many get any use?
Using python as an example here makes little sense, since the constraints of the problem domain make it a particularly poor choice. Try choosing a language that doesn't suffer as much in performance (future Rust, maybe?).
Re: FFmpeg and a thousand fixes
#90Earlier quoted context omitted.
> why do we programmers always feel we need to apologize for something that we did quickly, but has been running without incident for a number of years. The script is only treating the symptom, not the problem. It would be better to detect the files before they waste an hour of time, so you could tell the user instead of having them silently disappear. Maybe there is something you could do to fix the files. The progr…
> If they haven't needed to fix the bug in all these years just writing that script was obviously a good decision. Exactly this. There are an unbounded number of bugs which will cause this single symptom. I think detecting the symptom is exactly the right solution.
In theory. In reality, after treating one or two causes, the occurrence rate may fall to once a month or year.
I agree that mitigating the problem is a good first step though.