ureq

ureq copied to clipboard

Hi, I would like to help integrate this project into OSS-Fuzz.

• As an initial step for integration I have created this PR: https://github.com/google/oss-fuzz/pull/8373, it contains necessary logic from an OSS-Fuzz perspective to integrate Ureq, This includes developing initial fuzzers as well as integrating into OSS-Fuzz.

• Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects.

• If you would like to integrate, could I please have an email(s), it must be associated with a google account like gmail (why?). by doing that, the provided email(s) will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats.

• Notice the email(s) affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.

Hi @manunio! Thanks for working on this. Looking at https://github.com/google/oss-fuzz/pull/8373, it appears your fuzz target fetches an arbitrary URL with arbitrary headers. My understanding is that a good fuzz target shouldn't make network requests because (a) that makes them hard to reproduce, (b) that slows them way down, and (c) that potentially generates a lot of junk network traffic (though since most arbitrary URLs won't parse, that's not really an issue).

I think a more useful fuzzer would generate arbitrary HTTP responses and ask ureq to parse them. Any crash parsing one of those responses would be considered a bug. There may be other areas of ureq that are also good fuzz targets (for instance cookie parsing, or parsing of other specific headers like Content-Length or Transfer-Encoding).

If you decide to pursue this further, I'm happy to provide an email.

Hi @manunio! Thanks for working on this. Looking at google/oss-fuzz#8373, it appears your fuzz target fetches an arbitrary URL with arbitrary headers. My understanding is that a good fuzz target shouldn't make network requests because (a) that makes them hard to reproduce, (b) that slows them way down, and (c) that potentially generates a lot of junk network traffic (though since most arbitrary URLs won't parse, that's not really an issue).

Hi @jsha, Thanks for the review, generally before creating any fuzzer, I tend to view already integrated projects/fuzzers or unittests to see how similar projects implement those fuzzers, as ureq being a http client i found two projects https://github.com/hyperium/h2/fuzz/fuzz_targets/fuzz_client.rs and https://github.com/hyperium/httpfuzz/src/fuzz_http.rs doing similar things as me, so that's how using arbitrary values for uri, headers came from. :)

I think a more useful fuzzer would generate arbitrary HTTP responses and ask ureq to parse them. Any crash parsing one of those responses would be considered a bug. There may be other areas of ureq that are also good fuzz targets (for instance cookie parsing, or parsing of other specific headers like Content-Length or Transfer-Encoding). If you decide to pursue this further, I'm happy to provide an email.

That's a great idea, we can work towards that and if you like towards the goal of achieving ideal integration with oss-fuzz, but before that I'd like to get started with this project get integrated as an initial integration(once pr gets accepted).

If you wish, i can keep my email id (i have done this for other projects) with existing fuzzers and later when we extend them, other mail can be added.

@jsha friendly ping :)

If you decide to pursue this further, I'm happy to provide an email.

That was my aim, i do wish to pursue it further with the goal of ideal-integration.

Additionally, If you wish i can keep my email till this and additional fuzzers are fully integrated and will keep ureq's team updated of any valid bugs or other relevant issues found, while the fuzzers are being developed and merged.

Hi @manunio! Thanks for the ping.

I still think your pull request to oss-fuzz has a problem: it is trying to make a "real" network request. You pointed out that h2 appears to do the same thing, but on closer inspection, it actually mocks out the network I/O:

https://github.com/hyperium/h2/blob/756e2524ac53c0cf9810efcba0b92171b7d80e42/fuzz/fuzz_targets/fuzz_client.rs#L18-L20

The next step here is to improve the fuzz target so it doesn't do any real network I/O. One approach would be to mock out the I/O. For instance you might be able to do this with the ReadWrite trait we already have.

Another approach would be to change what you target for your first fuzzing integration. For instance, perhaps instead you would like to generate arbitrary response bodies and pass them through our parser? That way you avoid any network I/O.