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

91–100 of 150 posts

Re: FFmpeg and a thousand fixes

#91

Post by berdario »

vezzy-fnord wrote: post #69
Perseids wrote: post #48

Earlier quoted context omitted.

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: w00…

There's also AT&T Labs' memory-safe dialect of C called Cyclone: http://cyclone.thelanguage.org/ It's been around since 2006, but I haven't really heard of anyone using it. I wonder why.

Cyclone has been dead since years (the last release is dated 5 May 2006)

It never compiled on 64bit architectures, and to get it to compile with 4.0 or 4.1 (newer versions of gcc won't work) you need to fetch it from SVN (last commit is dated May 2009)... and obviously: no distribution still ship such an old version of the build tools... you'd need something like debian lenny, which does not even receive security updates anymore

Re: FFmpeg and a thousand fixes

#92

Post by gcr »

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.

Would you really want to try and write a high-quality video encoder in any other language? Now surely you aren't recommending switching to hand-tuned assembly! :)

Re: FFmpeg and a thousand fixes

#93

Post by ori_b »

jbk wrote: post #86
chubot wrote: post #84

Earlier quoted context omitted.

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

What you do is split the file I/O from the rendering. Drop privs on the renderer, and feed it data from another process that handles the file access, setup, and other privileged operations.

You can open your X11 socket (or whatever your GUI uses) in the I/O process and hand it off to the renderer before dropping privileges, and hand it off without any loss of performance. Another thought -- although I don't generally touch 3d rendering, or know enough to know if it's possible off the top of my head -- is something like cross-process pbuffers: you render into one, and composite the result to the screen from another process. Since your OS already does this sort of thing (X11 compositors, for example, do this sort of cross-process compositing), this can't be too expensive.

You might need to use the XACE extension to restrict the renderer to just the rendering output window in case it gets exploited, so that you don't have access to the rest of the UI.

The places where vulnerabilities can do damage are when communicating with the rest of the OS: File I/O allows you to get user data, permanently install malware, and delete things. The window system allows you to snoop keystroke/mouse data, synthesize input, and watch what the user does. Drop privs on those, and your app is fairly effectively sandboxed.

Re: FFmpeg and a thousand fixes

#94

Post by gcr »

haberman wrote: post #66
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.

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages that make C programmers choose C. Meanwhile, you are just being snarky on a message board while using a whole stack of software that was built by the programmers whose work you are criticizing.

This list of criticism is copied verbatim from the article's list of fixed bugs, not composed directly by the OP.

Re: FFmpeg and a thousand fixes

#95

Post by scott_s »

gcr wrote: post #94
haberman wrote: post #66

Earlier quoted context omitted.

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages that make C programmers choose C. Meanwhile, you are just being snarky on a message board while using a whole stack of software that was built by the programmers whose work you are criticizing.

This list of criticism is copied verbatim from the article's list of fixed bugs, not composed directly by the OP.

The snark, however, is wholly original.

Re: FFmpeg and a thousand fixes

#96

Post by ajross »

haberman wrote: post #66
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.

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages that make C programmers choose C. Meanwhile, you are just being snarky on a message board while using a whole stack of software that was built by the programmers whose work you are criticizing.

Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. So perhaps the "some of these problems" is perhaps a bit spun.

Rust looks great for apps and middleware. I don't see ffmpeg or x264 (both of which are implemented with significant amounts of architecture-specific machine code -- an environment where neither C nor Rust is going to be able to help avoid the kind of bugs we're talking about) jumping ship any time this decade.

Re: FFmpeg and a thousand fixes

#97

Post by emmelaich »

Bit off topic but I may as well bring this up here.

  1. flvrunner uses ffmpeg
  2. biggest result for flvrunner searches is how to remove flvrunner (including browser toolbars)
  3. doubleclick runs webads for flvrunner.com (google own doubleclick)
  4. such ads even run on onlinebehavior.com, which is owned by Google's analytics guy.
There's a lot of malware on the net that google could do more to reduce.

Someone more conspiratorially minded than me might make other deductions.

Re: FFmpeg and a thousand fixes

#98

Post by burntsushi »

rip747 wrote: post #54
chadillac wrote: post #47

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

"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

Because if we don't, our programming brethren will assume that we thought the fix was correct and optimal. And we'll get bashed for it.

Haven't you ever heard of the quip (summarized): "The quickest way to get help from a technical crowd is to claim what you're doing is correct. People will bend over backwards to prove you wrong."

Re: FFmpeg and a thousand fixes

#99

Post by Crito »

kbenson wrote: post #89
Crito wrote: post #63

Earlier quoted context omitted.

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

Oh, I agree. I think that C was the right choice for FFmpeg, at least at the time, and I do not think that python would be the right choice for it today.

I'm just making a point that language is relevant when discussing the type and frequency of errors that are surfacing in a project.

Post reply on HN