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

101–110 of 150 posts

Re: FFmpeg and a thousand fixes

#101

Post by haberman »

ajross wrote: post #96
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.

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

Yeah I don't think it's likely either. But it's a lot more likely than Modula-2, Ada, or any of the other languages that the OP would be arguing of in favor of C.

OP is criticizing without a plausible alternative; Rust is at least more plausible of an alternative. But I also suspect that C+ASM will continue to rule the day here, especially now that these fuzzing techniques are become more widespread and industrial-strength.

Re: FFmpeg and a thousand fixes

#102

Post by pcwalton »

ajross wrote: post #96
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.

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

> Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero.

I'm not claiming it's production quality, but I did write an MP2 decoder in an early version of Rust: https://github.com/pcwalton/fempeg

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

I grepped through the commit log for bugs marked "j00ru", as suggested in the post, and the first 20 I found were all mostly-architecture-independent, straightforward C code (often bitstream parsing code). This is the kind of problem that Rust is generally good at securing and making performant. None of the 20 patches I looked at touched any assembly code at all.

Re: FFmpeg and a thousand fixes

#103

Post by lhgaghl »

ID_HOME wrote: post #28
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.

If Java is somehow a problem, you can simply make a language without stack smashing but also without GC. Nobody has done this so far because nobody gives a shit about the fact that every program we use is full of remote code vulns and will never be fixed.

Re: FFmpeg and a thousand fixes

#104

Post by al2o3cr »

Perseids wrote: post #48
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".

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…

"that can eliminate nearly every memory management related vulnerability"

This is like saying "my bulletproof vest will stop nearly every round fired at it". Too bad it only takes ONE...

Re: FFmpeg and a thousand fixes

#105

Post by Nitramp »

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.

Criticism is good if valid, and it is in this case.

Re: FFmpeg and a thousand fixes

#106

Post by pcwalton »

haberman wrote: post #101
ajross wrote: post #96

Earlier quoted context omitted.

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

Yeah I don't think it's likely either. But it's a lot more likely than Modula-2, Ada, or any of the other languages that the OP would be arguing of in favor of C. OP is criticizing without a plausible alternative; Rust is at least more plausible of an alternative. But I also suspect that C+ASM will continue to rule the day here, especially now that these fuzzing techniques are become more widespread and industrial-st…

Fuzzing has found plenty of security vulnerabilities, to be sure, but I'm skeptical that it makes static analysis obsolete. Even if it were possible to write a theoretical fuzzer that would find every possible security vulnerability, it'd still be a whole lot cheaper, and easier, to just have a tool that enforces that you write the code correctly in the first place than to spend time writing it in an unsafe language and then developing a world-class fuzzer to find all the vulnerabilities.

Re: FFmpeg and a thousand fixes

#107

Post by lhgaghl »

Raphael_Amiard wrote: post #88
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".

Ada would have been a good one, and mature enough. :)

A) Ada isn't sexy and unproven B) Most people who do mad algorithmz don't give a fuck if they introduce security vulns (even if they do, they don't know that other languages exist other than C), nor do they care about other languages (probably are put off by the facts that 1. other mainstream languages don't support mad algorithmz (Ada isn't mainstream) 2. if you look up any mainstream programming language you get nothing but dogma)

Re: FFmpeg and a thousand fixes

#108

Post by ajross »

pcwalton wrote: post #102
ajross wrote: post #96

Earlier quoted context omitted.

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

> Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. I'm not claiming it's production quality, but I did write an MP2 decoder in an early version of Rust: https://github.com/pcwalton/fempeg > 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 enviro…

My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly.

But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post.

Re: FFmpeg and a thousand fixes

#109

Post by pcwalton »

ajross wrote: post #108
pcwalton wrote: post #102

Earlier quoted context omitted.

> Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. I'm not claiming it's production quality, but I did write an MP2 decoder in an early version of Rust: https://github.com/pcwalton/fempeg > 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 enviro…

My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say),…

> My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly.

I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem.

> But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post.

Of course, no argument there. I am reasonably confident that we can get there with tuning though, based on our benchmarks so far. :)

Re: FFmpeg and a thousand fixes

#110

Post by haberman »

pcwalton wrote: post #106
haberman wrote: post #101

Earlier quoted context omitted.

Yeah I don't think it's likely either. But it's a lot more likely than Modula-2, Ada, or any of the other languages that the OP would be arguing of in favor of C. OP is criticizing without a plausible alternative; Rust is at least more plausible of an alternative. But I also suspect that C+ASM will continue to rule the day here, especially now that these fuzzing techniques are become more widespread and industrial-st…

Fuzzing has found plenty of security vulnerabilities, to be sure, but I'm skeptical that it makes static analysis obsolete. Even if it were possible to write a theoretical fuzzer that would find every possible security vulnerability, it'd still be a whole lot cheaper, and easier, to just have a tool that enforces that you write the code correctly in the first place than to spend time writing it in an unsafe language…

Totally agree that static analysis is better than fuzzing for preventing memory-safety vulnerabilities. If ffmpeg can be written in Rust without any disadvantages compared to C, then that's an easier way to ensure memory safety than fuzzing. I would be surprised if Rust can compete against C anytime soon for writing codecs, but will be pleasantly surprised if it can!
Post reply on HN