I don't think it's plausible OSS-Fuzz could have found this. The backdoor required a build configuration that was not used in OSS-Fuzz.
I'm guessing "Jia Tan" knew this and made changes to XZ's use of OSS-Fuzz for the purposes of cementing their position as the new maintainer of XZ, rather than out of worry OSS-Fuzz would find the backdoor as people have speculated.
How many oss-fuzz packages have a Dockerfile that runs apt-get install liblzma-dev first?
Had this not been discovered, the backdoored version of xz could have eventually ended up in the ubuntu version oss-fuzz uses for its docker image - and linked into all those packages being tested as well.
Except now there's an explanation if fuzzing starts to fail - honggfuzz uses -fsanitize which is incompatible with xz's use of ifunc, so any package that depends on it should rebuild xz from source with --disable-ifunc instead of using the binary package.
This is interesting, but do you think this would have aroused enough suspicion to find the backdoor (after every Ubuntu user was owned by it)? I don't see why this is the case. It wasn't a secret that ifuncs were being used in XZ.
And if that's the case, it was sloppy of "Jia" to disable it in OSS-Fuzz and not do this:
to the XZ source code to fix the false positive and turn off the compilation warning, no attention would have been drawn to this at all since no one would have to change their build script.
With or without this PR, it's very unlikely OSS-Fuzz would have found the bug. OSS-Fuzz also happens to be on Ubuntu 20. I'm not very familiar with Ubuntu release cycles, but I think it would have been a very long time before backdoored packages made their way into Ubuntu 20.
I don't think we have plans to build this for now.
I find it a really cool idea, but for now, running fuzzers natively on Google Cloud with ClusterFuzz (https://github.com/google/clusterfuzz) suits our needs.
One challenge for the WASM approach is it will always be at least as hard to build a project for WASM as it is for native.
Right I think WASM offers some nice advantages over native for distributed fuzzing.
It's also worth pointing out that Mozilla made a (non-WASM) distributed fuzzing project, virgo: https://github.com/MozillaSecurity/virgo
but it appears to be inactive.
I haven't done a comprehensive study of this but in general I find that fuzzing programs in different environments (e.g. CPU architectures, OSes) tends to find some bugs that won't be found by fuzzing in just one environment.
But in general, I agree a lot of the bugs in WASM apps could be found by fuzzing their native versions.
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 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.
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.
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.
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.
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.
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.)
I don't think it's plausible OSS-Fuzz could have found this. The backdoor required a build configuration that was not used in OSS-Fuzz.
I'm guessing "Jia Tan" knew this and made changes to XZ's use of OSS-Fuzz for the purposes of cementing their position as the new maintainer of XZ, rather than out of worry OSS-Fuzz would find the backdoor as people have speculated.