Hacker News new | comments | ask | show | jobs | submit login
Open-Sourcing ClusterFuzz (googleblog.com)
292 points by markoa 10 days ago | hide | past | web | favorite | 83 comments





I work on this. Happy to answer questions if people have any.

How does the decision get made at Google to open source something?

I'm always confused about what gets shut down vs open sourced vs paid product.


Hi there! I work in the Google Open Source Programs Office. Echoing what others have said, it's usually just a matter of an engineer or team deciding it's something they want to do. Other times, it's a strategic choice.

We open sourced our open source policies/docs a while back, so if you're so inclined you can dig deeper there. These two links will be of particular interest: https://opensource.google.com/docs/creating/ and https://opensource.google.com/docs/why/


+1

I can speak a little bit about what motivated us.

We saw from OSS-Fuzz (https://github.com/google/oss-fuzz) that this sort of thing could be widely useful and wanted non-open source code to benefit from making fuzzing easier.


Thanks Josh! Love the meta-open sourcing.

I would guess that it has to do with the usefulness of the project outside of Google. This project could be applied to so many other things (as OSS-Fuzz demonstrates), so open-sourcing it makes perfect sense. It isn’t some kind of classified algorithm, either.

Open sourcing is usually pushed from the bottom. People decide they care about open sourcing their project at they push for it.

Any plans to port this from GCE APIs to something more provider agnostic, like k8s? A lot of us would like to fuzz on on-prem equipment.

We would like to support this use case.

For now, you can actually do the fuzzing on prem while communicating with app engine. We do this for our OS X bots since GCE doesn't offer OS X.


The other possibility for completely on-prem use right now is running it using the dev server: https://google.github.io/clusterfuzz/getting-started/local-i...

Hi, good stuff! I am curious to know why it was primarily written in Python (according to GitHub 83.3%)?

Just generally speaking, code that does orchestration and testing in general is often easier under a dynamic scripted language over something that is built and compiled, even if it winds up as a custom DSL. I think Python is one of the better options here for the broader community support, and tooling.

Aside: I tend to reach for node/js often for similar reasons (despite detractors) mostly because I'm more comfortable with it over Python or Ruby, but also because it's already integrated to most of the build/test environments I'm working on anyway.


Python is great for writing glue code, so I'm not particularly surprised by the language choice.

I’m curious why you seem to be surprised? It’s one of the most popular languages (even within Google).

That's one of the main languages at Google. And there are moving towards more Go since a few years.

I am quite ignorant on this subject. I looked briefly through the docs, and still feel a little lost. So before I go too much further, would it be possible to use this for web apps or unity games?

>So before I go too much further, would it be possible to use this for web apps or unity games?

Web apps, almost certainly no.

ClusterFuzz (and fuzzing generally) is most useful for finding bugs in C/C++ code so maybe it could work for unity games? I don't know much about them though.


I thought unity was mostly written in either C# or an EcmaScript flavour?

Unity itself (the engine) is written in C++. Game scripts are written in either C# or UnityScript iirc.

Although the engine is currently written in C++, they are in the process of rewriting parts of it in C#, with help of their HPC# subset and Burst compiler, having some ex-Insomniac Games developers like Mike Acton on the team.

Is this the fuzzing tool that was used to find bugs in Bitcoin? I don't see it in the repository.

I don't think so.

But solidity was recently added to OSS-Fuzz: https://github.com/google/oss-fuzz/tree/master/projects/soli...


Keep up the good work, Johnathan! This is a great feature.

Congrats, Jonathan!

Thanks Tanin!

How does it compare to afl?

It uses AFL.

ClusterFuzz is infrastructure for running fuzzers, so we use it to run AFL, libFuzzer, and other domain specific fuzzers we've written.

Using it to run AFL gives us a lot of nice things over using AFL on someone's desktop (such as crash deduplication, automatic issue filing, fixed testing, regression ranges etc.)


Disclosure: I work on Google Cloud.

I'm super pleased to see this! Abhishek and the cluterfuzz team were one of our initial customers for Preemptible VMs, still are, and make for a great example. Congrats to the team!


I don't want to hijack the thread subject but here are my thoughts on the usefulness of fuzzing of safe languages.

Even in the absence of memory corruption bugs there is a subclass of bugs that can emerge in any general-purpose language, like slowness/hangs, assert failures, panics and excessive resource consumption.

Barring those, you can detect invariant violations, (de)serialization inconsistencies (eg. deserialize(serialize(input)) != input, eg. see [1]), different behavior across multiple libraries whose semantics must be identical (crypto currency implementations are notable in this regard as deviation from the spec or canonical implementation in the execution of scripts or smart contracts can lead to chain splits).

With some effort you can do differential 64 bit/32 bit fuzzing on the same machine, and I've found interesting discrepancies between the interpretation of numeric values in JSON parsers, which makes sense if you think about it (size_t and float have a different size on each architecture, causing the 32 bit parser to truncate values). This might be applicable to every language that does not guarantee type sizes across architectures like Go (not sure?), but I haven't tested that yet.

You can detect path escape/traversal (which is entirely language-agnostic but potentially severe) by asserting that any absolute path that is ever accessed within an app has a legal path, or by fuzzing a path sanitizer specifically.

And so on.

Code coverage is the primary metric used in fuzzing, but other metrics can be useful as well. I've experimented extensively with metrics such as allocation, code intensity (number of basic blocks executed) (which helped me prove that V8's WASM JIT compiler can be subjected to inputs of average size that take >20 seconds to compile), and stack depth, see also [2].

Any quantifier can be used as a fuzzing metric, for example the largest difference between two variables in your program.

Let's say you have a decompression algorithm that takes C as an input and outputs D. Calculate R = len(D) / len(C), so that R is the ratio between compressed input and decompressed output. Use R as a fuzzing metric and the fuzzer will tend to generate inputs that have a high compressed/decompressed size ratio, possibly leading to the discovery of decompression bombs [3].

Wrt. this, libFuzzer now also natively supports custom counters I believe [4].

Based on Rody Kersten's work I implemented libFuzzer-based fuzzing of Java applications supporting code coverage, intensity and allocation metrics [5], and it should not be difficult to plug this into ClusterFuzz/oss-fuzz.

Feel free to get in touch if you have any questions or need help.

[1] https://github.com/nlohmann/json/blob/develop/test/src/fuzze...

[2] https://github.com/guidovranken/libfuzzer-gv

[3] https://en.wikipedia.org/wiki/Zip_bomb

[4] https://llvm.org/docs/doxygen/FuzzerExtraCounters_8cpp_sourc...

[5] https://github.com/guidovranken/libfuzzer-java


Great post Guido!

Guido's bignum fuzzer which tests the correctness of math operations in crypto libraries is one of the most interesting fuzzers we run on ClusterFuzz.


Thank you for open sourcing this. For those interested in trying multiple cluster-based fuzzing solutions, I'd also like to point at yahoo/yfuzz[1], which is k8s-backed.

[1] https://github.com/yahoo/yfuzz


For those interested in the repo: https://github.com/google/clusterfuzz

Is there a fuzzing tool oriented towards web applications? Something that could generate loads of Selenium cases automatically and verify whether the application crashes, logs an exception or continues to work smoothly??

There are a boatload of pentesting (i.e. penetration testing) tools that use fuzzing. Just be sure that your sysadmin and / or your cloud provider are aware that you intend on running such a test, as that's a really quick way to accidentally bring down servers you weren't anticipating would be connected, or get your IP address banned for DDOS attacks (looking at you, junior QA guy who had good intentions but caused all sorts of havoc).

Edit: Just realized I didn't quite address your question fully. https://pentest-tools.com/home is an online service that will run tests, including URL fuzzing and what not. All of the features they offer can also be found in open source and proprietary software. Not sure about saving failed tests as selenium tests for re-running in the future, though I imagine that you'd just re-run the same tool in the first place.


What open source did you mean? I'd like to run such tests on the intranet, without access to any SaaS.

Last time I tested https://github.com/s0md3v/XSStrike whith some quite interesting results. It's important to note that it's not a fizzbuzz tool, but just a pentest one.

Perhaps a noobie question, but it mentions c/c++ specifically. How does this hold up for Go? Where you have pointers but no pointer arithmetic?

Go software can exhibit a variety of denial-of-service bugs such as slice out-of-bounds access (since there is no try/catch mechanism, this leads to a panic), excessive allocations, excessive computation/timeout (consider "for i := 0; i < N; i++" where N is untrusted), stack overflow due to unbounded recursion (rare because Go has a custom, large stack).

My bignum-fuzzer project [1] runs on oss-fuzz and tries to find mismatches between bignum computations across different libraries (OpenSSL, Go, Rust, etc). This is one example of how fuzzing can be useful even if the underlying language is "safe".

With some small hacks you can also have Go code coverage instrumentation as a libFuzzer counter.

[1] https://github.com/guidovranken/bignum-fuzzer/blob/master/mo...


And Go isn't memory safe given race conditions.

If you're using goroutines you may want to consider fuzzing with the race detector.


That's a nice explanation, thank you. I'll take a look at implementing it in some small piece of software :)

There are tools for fuzzing go: https://github.com/dvyukov/go-fuzz

But I think the kinds of bugs found by fuzzing aren't generally security issues in go (I don't know much about go) as they are in C/C++.

EDIT: See guidovranken's excellent sibling comment for how fuzzing can still be useful for go.


Awesome, I will check that out. Thank you!

How about people stop using unsafe languages such as C and C++?

Rust without the use of unsafe code is considered by most to be a safe language but nonetheless, it's still useful to fuzz it to find logic bugs (like assert failures) or anything that triggers a panic (like out of bound array access or integer overflow).

More info: https://github.com/rust-fuzz

Disclaimer: I am the author of the rust fuzzer honggfuzz-rs.


What planet do you live on? What do you think embedded/realtime systems, signal processing, graphics, and kernel developers are supposed to use? Also, what do you think these memory-safe, garbage collected, runtime environments are written in?

> What do you think embedded/realtime systems, signal processing, graphics, and kernel developers are supposed to use?

My guess is that they'd use Rust for new code.


Rust doesn't yet support every platform that C supports and training staff to use a new language and adding tooling to integrate a new language into an existing codebase is extremely expensive.

I don't even know Rust, so there's a reason I write low-level stuff like that in C/C++ ;)

Fuzzing is effective for more than finding memory related bugs. Parsing related crashed, code injection, unexpected state machine path can all also be revealed.

Beside, as much I agree with the benefits of a memory safe language, and I do believe in the urgency of promoting techs like rust, C and C++ are going to be part of our lifes for a lot of time.

If you gotta use knife, make sure you have the tools to make it sharp.


Even if everyone switched to writing Rust/Swift/$SAFE_LANGUAGE today, there are many, many projects that are written in C/C++ that aren't going to disappear overnight.

Makes you think about choosing to write software in C / C++ / other non-memory-safe languages when you need 25000 cores churning away to ensure you don’t make mistakes that could cause serious security issues.

It makes me wonder why Google wouldn’t put their efforts into using Rust, for example.

Of course, server power is cheap, but not for our planet.


I know some embedded/kernel devs and they don't take Rust very seriously. I don't think it has a lot of mindshare in industry among the kind of people who currently write C.

Even if all new code was written in safe languages we would still need to do fuzzing until all legacy code was rewritten -- operating systems, SSL libraries, browsers, load balancers, etc.


I know lots of embedded/kernel devs (I am one) and lots of them are at least interested in Rust. It does have mindshare.

I truly believe that's the only reason people aren't using Rust as a replacement for C / C++ immediately. The adoption isn't widespread, but I'm rather optimistic it will be.

It's getting there.


I don't think it's the only reason.

My C programmer friends like the dangerous features of the language and want to use them. Their programs are designed around the assumption that they can mutate anything in memory whenever they want to. They use mutable global variables. They would strongly dislike Rust's memory protections and ownership concept, and its other safety features.


To what purpose? It sounds like they are being reckless just for the heck of it, because that's how the big boys do it and they can't be bothered to learn a new skill.

Even if you use Rust (or other memory safe(r) languages), you still have a variety of failure modes that they don’t protect against, with which fuzzing may be helpful: poor resource handling (e.g. massive memory allocations), logic problems in program, busy loops, all kinds of assertions, exceptions, etc. triggering of which may lead to DoS, or other undefined behaviors. Sure: not as critical , depending your threat model , as remote code execution, but things that should be found and fixed from any code base that is part of something that people use.

Google is putting effort into using Rust, but in more greenfield work, like Fuchsia.

Integrating a new language into a new codebase is a lot of work; it would be great if Chromium started using it, but I also understand why it may be a harder sell there. Engineering is all about tradeoffs.


Well, don't most of their internal systems already run tooling that is already written using Linux and Gnu libraries? Wouldn't it make sense to do testing on what they already have available instead of some theoretical ground up replacement effort?

Not to say there isn't work on replacement efforts, only that testing what is in use is a practical thing, even if the scale is surprising.


> It makes me wonder why Google wouldn’t put their efforts into using Rust, for example.

Well some newer projects in Chrome/Chromium are written in Rust so for what it's worth there is some effort.

I believe just yesterday the security team published a document which recommended avoiding unsafe languages for safety critical code: https://chromium.googlesource.com/chromium/src/+/master/docs...


I don't see Rust in the list of approved safe languages for chromium at https://chromium.googlesource.com/chromium/src/+/master/docs...

I don't think that's a list of approved languages but "likely candidates"?

But apologies perhaps I confused Chromium for Chromium OS: https://chromium.googlesource.com/chromiumos/docs/+/master/r...


Is there an actual list of approved languages?

Rust is listed a little higher in that link in the section about avoiding unsafe implementation languages. Given that they list it as a counterexample of things to avoid I would assume that means it is good, but that is no sure thing.


It's present in some newer projects, notably Fuchsia.

Have to say that nothing can make your program automatically safe (defined by common sense, not "memory leaks are also memory safe"[0]) without any effort, and the trend to claim some languages are inherently "safe" while others are not is definitely a hype. Modern C++ plus static analyzing (Chromium rolled out their own Clang plugins to do that) provides better flexibility.

[0]: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...


Virtually nobody in security agrees with you. Memory-safe languages do effectively mitigate some of the most critical security issues.

C++ static analysis is helpful, but it is not memory safe. Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free.


People drastically underestimate the prevalence and impact of UAF attacks. They're extremely common in complex applications and often lead to everything from information leaks to code execution. That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain.

> That's why almost every browser exploit (of the last ~10 years at least) uses at least one UAF in their chain.

That's usually because the "low-hanging fruit" is mostly gone due to protections like stack canaries, CFI checks, address randomization, and sandboxing, which makes things like buffer overflows or jumping to shellcode more difficult.


Yet the Linux Kernel Self Preservation project is still in a getting there kind of state.

Sorry, what?

That low hanging fruit is not gone on the Linux kernel, for more info check Linux Kernel Summit 2018 and Linux New Zealand Conference 2019.

> Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free.

I think modern C++ is much safer than legacy C++, not by disallowing the USE after free, but by giving you the tools to make sure that the FREE happens at an appropriate time. A lot of this is not necessarily a feature of the language itself, but of idioms the community seems to agree to ie CppCoreGuidelines. I'm thinking of

- never use the delete operator manually, prefer std::unique_ptr

- prefer single ownership over shared ownership

- prefer immutable over mutable state

- ...

I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe.


When people use the delete operator manually and mess up, do they usually delete objects too early or too late? In my experience, they usually delete objects too late or not at all (though I admit to not having hard data here). Accordingly, most of the benefits people cite regarding RAII classes such as unique_ptr are that they reduce memory leaks. I would agree that they do. But memory leaks aren't nearly as severe as use-after-free.

Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. References are used all the time in C++, and you can't use any libraries without them. It doesn't matter if data has a single owner if that owner is deleted and you still hold references to the data. In fact, shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.


> Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics.

Shared ownership makes it much harder to reason about lifetimes, increasing the chance of mistakes.

> shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.

Only if the dereferencing code holds the shared_ptr. It's also common to pass non-owning pointers to objects held by shared_ptr.

> When people use the delete operator manually and mess up, do they usually delete objects too early or too late?

As you pointed out, problems arise if objects are deleted too early or twice. Double free is common in C and can be exploited as well...


> I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe.

Well if it isn't getting any safer than the time-disproven technique of relying on human behaviour and there are automatically safer alternatives, then it is less safe than those alternatives.


Sure, but the argument was that newer C++ standards make the language less safe.

That is the thing though, I never did code reviews in C++ projects and have been often in the past (in my C and C++ days) the dude playing the D.Quixote role about static analysers.

Modern C++ is safer, but only if you can ensure everyone on the team never reaches for C style tricks, nor the libraries that you link against.


Can a memory leak be the root cause of memory corruption? No: there has to have been some other problem, which is why it is worth separating it from other more dangerous "safety" issues.

Personal option: Separating leak from UAF and claim the former is more acceptable should not be the case, because leak applies to more than memory, and leaky fds can also create security holes like [0]

[0]: https://labs.portcullis.co.uk/blog/exploiting-inherited-file...


Accidentally "leaking" fds to a child process due to a resource leak would be a great example! However, I still feel memory/resource leaks are not the same as memory corruption. Memory corruption is more fundamental: it can be used to cause a leak, but a leak cannot be used to cause memory corruption. That is, being memory corruption-free is a necessary prerequisite for a program to also be leak-free (it isn't sufficient, though).

Additionally, that example doesn't seem to be a resource leak in the sense of a memory leak. The exact same problem occurs if the file description is purposefully used after the 'system' call (that is, it isn't being leaked by not being used again). That's an issue more with 'system'/'fork' implicitly inheriting file descriptors than a resource being leaked.


This is more of an issue with setuid (which has all sorts of problems) than with leaks. Note that this issue would still occur with C++, or in any GC'd language if the GC didn't happen to run before the call to system().

Also note that Rust has contained a mitigation for that issue for a long time now: https://github.com/rust-lang/rust/pull/24034


That kind of mitigation just makes me one step away from Rust - system programming languages should stick to the platform behavior, otherwise it's just another Python. Moreover this change is not documented anywhere else. Have a look at how GLib handle these cases[0]:

> - during the GSubprocess discussion, I originally held the opposite opinion, but eventually became convinced (by Colin) to see the inherit-by-default behaviour of exec() as nothing more than a questionable implementation detail of the underlying OS. Consequently, at the high level, GSubprocess provides an API that gives the caller direct control over what is inherited and what is not, and that's just the way that it should be.

> - this behaviour is not limited to GSubprocess. Closing all fds before calling exec() is a common practice in modern libraries and runtimes, and for good reason.

[0]: https://mail.gnome.org/archives/gtk-devel-list/2015-March/ms...


> That kind of mitigation just makes me one step away from Rust - system programming languages should stick to the platform behavior, otherwise it's just another Python.

That's silly. The standard library of new systems programming languages should do the safe thing, not inherit all the mistakes of the OS that the OS can't fix due to backwards compatibility. If Unix were being designed today, I am certain O_CLOEXEC would have been the default. Besides, Rust's behavior matches what happens on Windows, and cross-platform consistency in the standard library is desirable.

In any case, what glib does matches what the Rust standard library does. The latter uses posix_spawn() directly in order to make sure no file descriptors are passed between parent and child. There is an API available to request file descriptor sharing explicitly.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: