Coverage-based fuzzing for transaction processing, (de)serialization #2298
Closed
1 task
Labels
A-devops
Area: Pipelines, CI/CD and Dockerfiles
A-rust
Area: Updates to Rust code
C-security
Category: Security issues
I-heavy
Problems with excessive memory, disk, or CPU usage
I-invalid-data
Zebra relies on invalid or untrusted data, or sends invalid data
Motivation
We currently test transaction (de)serialization and processing to a degree with structured property-based testing and unit testing. Structured proptests utilize test data that is correct, up to a point. While this is useful testing, we do want to cover more edge cases and abstraction/assumption mismatches.
Solution
We'd like to set up a coverage-based fuzzing harness to exercise transaction (de)serialization and processing. Fuzzing helps find logic and correctness bugs, even in a memory-safe language like Rust.
cargo-fuzz is the defacto standard tool, it wraps libFuzzer and has support for other fuzzing libraries, and builds well into a cargo crate/workspace.
They have a handy book to get started. There is also recent support for something closer to proptests, with structure-aware fuzzing.
auto-fuzz-test exists, but may collide with our use of
proptest::Arbitrary
or make code difficult to parse for humans.We should at least:
Transaction
implementations ofZcashDeserialize
,From
, etcWe can run this coverage are purely part of our CI, or we can consider integrating our fuzzing harnesses into oss-fuzz, for free, continuous fuzzing.
Alternatives
Keep pushing non-coverage-guided random data though code paths with our proptest framework. This may get us less bang for our buck.
Related Work
Merging the coverage data from coverage-based fuzzing with the rest of our test coverage data is possible, as they use the same llvm internals under the hood,
but may be annoyingshould be easy with CodeCov, could be considered out of scope for this ticket.The text was updated successfully, but these errors were encountered: