https://github.com/frewsxcv/afl.rs (discussion https://news.ycombinator.com/item?id=11936983)
I don't think they mentioned fuzzing their Brotli decompressor in this article, but I hope they try afl-rust.
https://github.com/frewsxcv/afl.rs (discussion https://news.ycombinator.com/item?id=11936983)
I don't think they mentioned fuzzing their Brotli decompressor in this article, but I hope they try afl-rust.
"Yes, performance has not been a focus point at all so far. I've started this project as a a way to get familiar with Rust, and also with the Brotli spec. For the implementation, I have made it a point to work only from the spec, while avoiding looking at the reference implementation, because another goal was helping to improve the Brotli spec itself. I do believe that there are a number of places where copies could be avoided, and other places where I used clone() simply because at the time I was unable otherwise to appease the borrow checker.
For a performance-oriented implementation, I would probably take the test cases and experiences so far, and start over with a new implementation."
I ran AFL on rust-brotli for a week a couple weeks ago. It didn't find anything. I plan to try again soon! No one is safe from AFL.
EDIT: I forgot to mention: It's possible to run AFL on uninstrumented code, it just won't be that smart about finding new code paths.
True, but the Rust bindings necessarily contain tons of unsafe FFI code, and those bindings enforces many required safety properties. Even without checking the underlying C code, running AFL to check for any unsafe holes in the bindings would help.
That said, yes, for best results you'd want to check the combination of C and Rust to find new paths and full coverage on both.