Hacker News Reader

Comment by steakejjs | Hacker News Reader

This research lcamtuf has been doing with AFL is really important.

One thing that it is proving (exactly as a lot of people expected) is, we don't have any idea where security bugs (think the next heartbleed or shellshock) are going to show up, we have no idea how good the software out there is (meaning it is bad), and most of the time we don't even know what's running on our own boxes.

If these basic things we use hundreds of times a day (less, strings) have huge flaws, we have a lot of work ahead of us.

View on HN

They will never go away while people insist in using C and its derivatives to write userspace code.

This is covered in the fuzzing project's FAQ https://fuzzing-project.org/faq.html

"if you start a new software project it is a good idea to avoid C right from the start. however ... most major software components we use today [are] written in C. Rewriting things from scratch is hard, compared to that finding bugs with fuzzing is the low hanging fruit."

While something like Go has good performance, writing low-level tools in interpreted languages (Python, Ruby, etc) means you would always have the performance overhead of firing up the interpreter for everything. A hypothetical non-C system would feel sluggish compared to what we have now.

Who said anything about interpreted languages?

Modula-2, Modula-3, Go, D, Haskell, OCaml, Oberon, Ada, Extended Pascal, Object Pascal, C#, Java, ...

The list of languages with native code compilers is quite big, no need for interpreters.

The problem with fuzzing is that, like the use of safer languages, it just won't get adopted unless forced down the throat of developers.

This is why, Google, Microsoft and now Apple are adopting a "our way or the high way" in memory safe languages for their platforms. After all, proprietary APIs would already be enough for platform lockin.

I do agree no one is going to re-write the huge amount of code out there. However it is already good enough if new code get written into something else.

It's not just about native vs interpreted though. Most of those languages use garbage collection for memory allocation which is still going to be an unacceptable performance hit for most of the domains where C and C++ are still in use.

Unless one is writting device drivers, kernel modules, signal processing algorithms or anything else that needs to fit in 16ms, there is hardly any reason to use C or C++.

Languages like Object Pascal, Modula-2 and Ada that don't use garbage collection and many that do, like Modula-3 provide much more control about value types and GC behavior than what Java and C# are known for.

Finally many of the garbage collection jitter issues are caused by developers clueless about writing GC friendly algorithms or simply how to use a profiler.

What about Rust from Mozilla?

Shellshock didn't have anything to do with C. gotofail looked like an SCM merging bug, which could have happened in any language. Security issues in the Rails world are often caused by libraries that do more than they should, just like less does (YAML comes to mind).

Yes, it would be nice to get rid of one class of errors. But proper sandboxing would get rid of them all.

Yeah those are the famous ones, but what's much more likely is that you're not going to necessarily be working on a project with as wide a footprint as any of those, and you're probably not going to create a bug that's quite as harmful as any of those either, but you're still going to cause memory-management problems for your project if you start out writing C.

No one's saying it's impossible to write memory-safe C code, it's just exponentially harder, and when you're not 100% sure of your use case and exact performance needs, you're going to spend a lot more time than you want to making C do only what you want and nothing else.

No. Even a perfectly sandboxed Apache could be subverted to send modified (malicious) data to other http clients. Sandboxes are great, but just because something's sandboxed doesn't mean all security issues are now reduced to a DoS.

While true, out of bounds errors, pointer misuse and undefined behaviors are the top exploits of any C code base, removing them would already be a big improvement in security.

You're absolutely right. Actually, this bug doesn't have anything to do with C either. You could probably get less to delegate to some vulnerable shell script utilities. You just have to find one case of "rm -- $INPUT" where someone left out the --, and put in an -rf as input.

It's good to keep spreading awareness and AFL is cool. As for proving new things... fuzzing has been actively used for security research for 15+ years, and by now it's common knowledge that C/C++ programs are rarely safe against untrusted input.

Reply on news.ycombinator.com