FFmpeg and a thousand fixes • Hacker News Board

Re: FFmpeg and a thousand fixes

#41

Post by chubot » Fri, Jan 10, 2014, 8:30 PM UTC

fulafel wrote: post #21

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.

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.

Section 5.2 in this DJB paper talks about (portable) isolation of plain transformations. Video playing is already close to "pure" or could be made pure pretty easily.

http://cr.yp.to/qmail/qmailsec-20071101.pdf

Re: FFmpeg and a thousand fixes

#42

Post by [deleted] » Fri, Jan 10, 2014, 8:30 PM UTC

gregcrv wrote: post #36

pjmlp wrote: post #22

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

programmers are people

[deleted]

Re: FFmpeg and a thousand fixes

#43

Post by feepk » Fri, Jan 10, 2014, 8:33 PM UTC

Thaxll wrote: post #24

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.

I'm sure some people are running VLC under root, still in userland but can be very dangerous.

This is one of the reasons why you have to use a wrapper for the VLC binary to execute it within a root environment. Said wrapper is usually in an extra package on Linux and not provided on Windows and OS X (it can be compiled manually of course). Like 10 people per year complain about not being able to run VLC as root, but then again, why should you?

Re: FFmpeg and a thousand fixes

#44

Post by pjmlp » Fri, Jan 10, 2014, 8:33 PM UTC

vinkelhake wrote: post #39

pjmlp wrote: post #31

Earlier quoted context omitted.

Before C escaped UNIX, there used to be safer system programming languages like Modula-2, just to cite an example. But Modula-2 had Lilith to offer, while C had UNIX.

There are other things to consider as well. Compiler support across various platforms: are there compilers available and do they generate good code? Mindshare: how big is the intersection of people who know the language and have the domain knowledge to contribute to the project?

When C was UNIX only, the generated code quality also had a lot to be desired.

Re: FFmpeg and a thousand fixes

#45

Post by dfc » Fri, Jan 10, 2014, 8:47 PM UTC

nathancahill wrote: post #16

craigyk wrote: post #13

Earlier quoted context omitted.

That is good. But this reminds me of the first time I installed 'ffmpeg' on Ubuntu only to have it not work with my well-tested parameters and also declare ffmpeg 'deprecated'. Only after some head scratching did I figure out it had installed libav and an ffmpeg wrapper that tried but failed to be compatible with the real ffmpeg interface. I wasn't even aware of the split at the time, but this shenanigan definitely g…

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

I thought that shenanigan was entirely the result of actions by a DD/UD and not upstream?

I really miss ffprobe, I can never get avprobe to work on the first or second attempt.

Re: FFmpeg and a thousand fixes

#46

Post by colanderman » Fri, Jan 10, 2014, 8:57 PM UTC

lmm wrote: post #27

vinkelhake wrote: post #25

Earlier quoted context omitted.

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

The only options I could think of that're mature enough are OCaml and Haskell. I'm aware of video transcoders in both, though nothing with anything like the format support of ffmpeg.

OCaml I know doesn't support SIMD acceleration. Not sure about Haskell. You need SIMD support to get anything decently fast in the field of video/audio manipulation.

Re: FFmpeg and a thousand fixes

#47

Post by chadillac » Fri, Jan 10, 2014, 8:59 PM UTC

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) in a production environment at this point... it processes thousands of videos a day using a custom queuing and reviewing system.

  1 = 60:00 (1 hour)
 27         if ($etime >= 6000) {
 28             $fail_sql = "DELETE FROM media_upload_queue WHERE queue_id = $queue_id";
 29             shell_exec("kill -9 ".$pid); // kill hung ffmpeg process
 30             $db->query($fail_sql); // remove file from DB
 31             // debate if life is worth living...
 32         }
 33     }
 34 }
 35 ?>

Yes I know there are better ways to do this now at the OS level, but it was a quick hack over a half decade ago and continues to work... ain't broke, don't fix it kinda deal.

Re: FFmpeg and a thousand fixes

#48

Post by Perseids » Fri, Jan 10, 2014, 9:01 PM UTC

vinkelhake wrote: post #25

pjmlp wrote: post #22

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

On the 30C3 there was a talk about a C Compiler (actually an llvm optimization plugin) that can eliminate nearly every memory management related vulnerability by adding memory checks. The penalty is only a 100% increase in runtime.

> If you're a C programmer and somebody says like: I've that optimization that makes your program 3% faster you go: wow! Then you come and say: well, now I make it half as fast you go: w00t?! But then you remember that people actually use ruby to serve web pages.

I'd say this would be actually worth it for a far more secure FFmpeg.

https://www.youtube.com/watch?v=2ybcByjNlq8

Re: FFmpeg and a thousand fixes

#49

Post by yincrash » Fri, Jan 10, 2014, 9:01 PM UTC

atmosx wrote: post #30

> At Google, security is a top priority - not only for our own products, but across the entire Internet. Hm, privacy was not on top, I guess - or we're toasted.

"a top priority" not "the top priority"

Re: FFmpeg and a thousand fixes

#50

Post by astrange » Fri, Jan 10, 2014, 9:07 PM UTC

nathancahill wrote: post #17

astrange wrote: post #15

Earlier quoted context omitted.

libav tries to ship a compatible wrapper called ffmpeg and a redone one called avconv. But ffmpeg itself just ships ffmpeg and puts incompatible changes in there, so you'd actually be worse off. What issues were you having, and with what file types?

Incompatible? Do you mean with libav?

Backwards incompatible with previous versions of itself.