metzmanj

Very interesting, this will really change the dynamics of bug bounty and webapp security more broadly

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:

``` __attribute__((__used__,__no_sanitize_address__)) ```

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 work on oss-fuzz.

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.

That's what people are saying though I haven't had the chance to look into this myself.

Fuzzing isn't really the best tool for catching bugs the maintainer intentionally inserted though.

>Woha, is this legit or some sort of scam on Google in some way?:

I work on OSS-Fuzz.

As far as I can tell, the author's PRs do not compromise OSS-Fuzz in any way.

OSS-Fuzz doesn't trust user code for this very reason.

No projects yet, but I bet we'll have some by next week.

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.

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