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

21–30 of 150 posts

Re: FFmpeg and a thousand fixes

#21

Post by fulafel »

jbk wrote: post #10
chubot wrote: post #5

This is cool. I wonder how many of the bugs led to code execution? If you managed to execute code, what privileges do you have in Chrome? I hope that Chrome was using OS sandboxing for video playing. After all, if they found 1000 bugs, there are probably a few more zero day's available. Does playing Flash video in Chrome/Firefox end up using ffmpeg? I'm not that knowledgeable about how video works, but there are prob…

> 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 memory. Negligible performance impact.

Re: FFmpeg and a thousand fixes

#22

Post by pjmlp »

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.

Re: FFmpeg and a thousand fixes

#23

Post by taeric »

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.

You forgot:

- One hell of an awesome encoder/decoder library that can hit more formats than I knew existed.

:)

Re: FFmpeg and a thousand fixes

#24

Post by Thaxll »

jbk wrote: post #10
chubot wrote: post #5

This is cool. I wonder how many of the bugs led to code execution? If you managed to execute code, what privileges do you have in Chrome? I hope that Chrome was using OS sandboxing for video playing. After all, if they found 1000 bugs, there are probably a few more zero day's available. Does playing Flash video in Chrome/Firefox end up using ffmpeg? I'm not that knowledgeable about how video works, but there are prob…

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

Re: FFmpeg and a thousand fixes

#25

Post by vinkelhake »

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

Re: FFmpeg and a thousand fixes

#26

Post by lmm »

A thousand, and all the categories they list are things the computer should catch for you. How many more will it take before we switch to better languages?

Re: FFmpeg and a thousand fixes

#27

Post by lmm »

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

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.

Re: FFmpeg and a thousand fixes

#28

Post by ID_HOME »

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.

I guess the correct solution is to use Java? Then we can bitch about run away garbage collection. How about Python then? It's really "fast". Or we can program it in snide remarks on forums, then we don't even have to write any working code to feel superior.

Re: FFmpeg and a thousand fixes

#29

Post by ID_HOME »

abraham wrote: post #7
IceyEC wrote: post #4

I get a kick out of the fact that they recommend not using FFMPEG but they say that Chrome uses it.

> I get a kick out of the fact that they recommend not using FFMPEG More specifically Google is recommending you don't use it to "process untrusted media files"

I don't trust any media files... Especially ones from Google who are doing most of the research... seriously though, media zero-days are unheard of, probably because they would be extremely valuable.
Post reply on HN