Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg and a thousand fixes

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

71–80 of 150 posts

Re: FFmpeg and a thousand fixes

#71

Post by jbk »

chubot wrote: post #41
fulafel wrote: post #21

Earlier quoted context omitted.

Chrome is also in userland - and it has a sandboxing system. Assuming they're sandboxing ffmpeg, these bugs are more risky for VLC users than Chrome users. Plus, Chrome is more diligent with security updates and the auto-update mechanism is fully automatic. A sandboxing system provided by either ffmpeg or VLC would be a very good idea, though it would be some work... encoded data in, decoded frames out via shared mem…

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 need to open files by yourself, without user interaction, to support playlists,

- you need to open connections by yourself to support video protocol like RTSP, RTMP, RTP,

- you need raw device access to support Webcams, Capture devices, DVDs, DVB tuners,

- you need to access GPU buffers for direct rendering, and/or shaders to do fast filtering or just plain chroma-conversions,

- you need to be able to access the audio output, at low-level, for libsync which is not always doable with the simplified APIs,

- and I don't understand what you mean by "very limited gui input"; how is that less than other programs?

Sure, it can be done, with performance costs but it's clearly not a "no-brainer".

Re: FFmpeg and a thousand fixes

#73

Post by bostik »

chubot wrote: post #41
fulafel wrote: post #21

Earlier quoted context omitted.

Chrome is also in userland - and it has a sandboxing system. Assuming they're sandboxing ffmpeg, these bugs are more risky for VLC users than Chrome users. Plus, Chrome is more diligent with security updates and the auto-update mechanism is fully automatic. A sandboxing system provided by either ffmpeg or VLC would be a very good idea, though it would be some work... encoded data in, decoded frames out via shared mem…

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 network connections

How about RTMP streaming? Or DLNA discovery and playback?

Some of the cases may be protected with sandboxing, but I have serious doubts about getting anything near complete coverage.

Re: FFmpeg and a thousand fixes

#74

Post by Perseids »

Crito wrote: post #62
Perseids wrote: post #59

Earlier quoted context omitted.

You mean, not many people use VLC? https://www.videolan.org/developers/vlc.html#thirdparty

For realtime playback locally sure. I don't think there are many/any public-facing systems backed by VLC. Presumably VLC prioritizes speed over security.

Oh, that was the point being made. My view is that VLC essentially is a public facing system, in the same sense that my browser is a public facing system. Sure, it is not as easy to do a targeted attack against my VLC as against my mail client (or against the nginx on my server). But it is fed a lot of untrusted data. The same goes for Chrome, which also uses FFmpeg according to the article.

Re: FFmpeg and a thousand fixes

#75

Post by jbk »

tptacek wrote: post #12
jbk wrote: post #10

Earlier quoted context omitted.

> I wonder how many of the bugs led to code execution? Quite a few. We're often affected with VLC, and code execution is easy to get to. But with VLC, you're "only" in userland.

In other words, you're "only" dealing with a bug that would allow anything you downloaded from BitTorrent to own up your personal account on your computer. :) (I know you know that, I'm just spelling it out for people).

Yep, and that's quite dangerous.

Especially since you can see often fake videos circulate around, that tell you to download a special software or codec to play them (with malware, of course). WMP also had a scripting/runtime system that could be abused greatly.

Be careful what you download :)

Re: FFmpeg and a thousand fixes

#76

Post by zaroth »

MBCook wrote: post #64
rip747 wrote: post #54

Earlier quoted context omitted.

"I'm not proud of this legacy code," "This cron has been keeping ffmpeg in check for over 6+ years in a production environment at this point... it processes thousands of videos a day using a custom queuing and reviewing system." 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. take a bow my friend. that was an awesom…

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

Re: FFmpeg and a thousand fixes

#77

Post by scrabble »

Until we can declare both projects "fuzz clean" we recommend that people refrain from using either of the two projects to process untrusted media files. You can also use privilege separation on your PC or production environment when absolutely required.

Well, it's not like I've got a whole lot of options for video processing. Note that they didn't recommend alternatives that they say are fuzz clean.

I use FFmpeg quite extensively and will continue to do so.

Re: FFmpeg and a thousand fixes

#78

Post by mastre_ »

chadillac wrote: post #47
samworm wrote: post #2

It 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…

Tell the truth, it's only been 4 years.

Re: FFmpeg and a thousand fixes

#79

Post by teddyh »

vezzy-fnord wrote: post #19
nathancahill wrote: post #16

Earlier quoted context omitted.

For sure. The story of FFmpeg and libav is full of sneaky shenanigans like that.

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?

Re: FFmpeg and a thousand fixes

#80

Post by jbk »

tlrobinson wrote: post #20

This must be one of the reasons it seems like there's a new update to VLC every time I launch it...

Yes. That's sad, but we need to update often, because of that.

And our update mechanism suck. We're working on improving the process because of that...

Post reply on HN