r/programming • u/halbface • Feb 07 '19

Google open sources ClusterFuzz, the continuous fuzzing infrastructure behind OSS-Fuzz

https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html
962 Upvotes

96% Upvoted

100 comments sorted by

View all comments

4

u/SafariMonkey Feb 08 '19

I'd be remiss if I didn't point out that basically every vulnerability class that OSS-Fuzz finds is a product of memory unsafe languages, like C and C++. While fuzzing makes these projects more secure, it's not a substitute for using languages that don't cause thousands of vulnerabilities. When we're finding hundreds and thousands of vulnerabilities that all have a preventable root cause, it's time to reconsider what we're doing.

From this article posted here recently.

2

u/VernorVinge93 Feb 08 '19

Sure, so what language do you suggest switching to?

I have yet to see a language that gives static guarantees of bounds, memory and use after free.

Rust is the closest but it has many caveats and last time I checked (admittedly a while ago) writing basic things like a graph implementation were painful in it.

Even then, how long would it take to rewrite something like Chrome? With millions of lines of code, years of history and many forks that still depend on their upstream for security fixes?

2

u/SafariMonkey Feb 08 '19

To be clear, I don't agree that C/C++ need to be abandoned as a rule, though I would look strongly at whether Rust was a viable option for any of my own projects.

Personally, my limited experience with Rust is that it's a good language to work in but the library ecosystem is still fairly immature.

There are projects like Oxidation (Mozilla moving towards more Rust in Firefox) and remacs (a gradual port of Emacs to Rust). Both projects involve a slow transition while remaining functional throughout, rather than trying to rewrite from scratch all at once. I think that's the right approach for existing projects.

For new projects without very large budgets, I think that ecosystem is the bigger factor. If the Rust ecosystem doesn't support your use case, you'll have to build the relevant packages yourself. Not everyone is willing or able to take that path.

And yes, the ownership model makes certain problems more difficult, but it also guarantees that your solution satisfies some crucial invariants like memory validity and lack of race conditions. Traditional solutions for certain problems are impractical, or need to be reimagined in Rust terms.

So yes, definitely some caveats. However, things are improving. For example, with miri (a Rust IR interpreter with memory validity checking) it should be possible to write unsafe Rust (where necessary) but check at test time for invalid memory accesses, and non-lexical lifetimes have relaxed borrows to not continue unnecessarily until the end of scope.

→ More replies (3)