3 ms·

Somewhat interesting for those who missed it - another rust/brotli project was a target for afl-rust. IIRC it didn't find any memory safety issues, but it defin

Somewhat interesting for those who missed it - another rust/brotli project was a target for afl-rust. IIRC it didn't find any memory safety issues, but it definitely exposed a few panic crashes: https://github.com/frewsxcv/afl.rs https://github.com/frewsxcv/afl.rs (discussion https://news.ycombinator.com/item?id=11936983 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.

sanxiyn 10y ago
Apparently this(https://github.com/dropbox/rust-brotli https://github.com/dropbox/rust-brotli) is much faster than the one(https://github.com/ende76/brotli-rs https://github.com/ende76/brotli-rs) fuzzed by afl.rs. Like 10x faster. See https://github.com/ende76/brotli-rs/issues/24 https://github.com/ende76/brotli-rs/issues/24.
- seeekr 10y ago
  Relevant comment from ende76 on why brotli-rs is relatively slow and what the goals of the project are/were: "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."
frewsxcv 10y ago
(afl.rs maintainer here) 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.
- JoshTriplett 10y ago
  Have you run AFL against git2-rs? I'd love to see that interface hammered on, to make sure it doesn't expose any unsafe behavior from the underlying library.
  - frewsxcv 10y ago
    I haven't, though I've thought about it. Most of the logic behind git2-rs (as far as I know) is written in C. While it's possible to run afl.rs on a Rust project that uses C code behind the scenes, I haven't ever attempted to get AFL instrumentation working on the underlying C code. I don't think it should be that difficult, I just haven't gotten around to it yet. 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.
    - JoshTriplett 10y ago
      > Most of the logic behind git2-rs (as far as I know) is written in C. 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.

sanxiyn 10y ago

Apparently this(https://github.com/dropbox/rust-brotli https://github.com/dropbox/rust-brotli) is much faster than the one(https://github.com/ende76/brotli-rs https://github.com/ende76/brotli-rs) fuzzed by afl.rs. Like 10x faster. See https://github.com/ende76/brotli-rs/issues/24 https://github.com/ende76/brotli-rs/issues/24.

seeekr 10y ago
Relevant comment from ende76 on why brotli-rs is relatively slow and what the goals of the project are/were: "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."

frewsxcv 10y ago

(afl.rs maintainer here) 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.

JoshTriplett 10y ago
Have you run AFL against git2-rs? I'd love to see that interface hammered on, to make sure it doesn't expose any unsafe behavior from the underlying library.
- frewsxcv 10y ago
  I haven't, though I've thought about it. Most of the logic behind git2-rs (as far as I know) is written in C. While it's possible to run afl.rs on a Rust project that uses C code behind the scenes, I haven't ever attempted to get AFL instrumentation working on the underlying C code. I don't think it should be that difficult, I just haven't gotten around to it yet. 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.
  - JoshTriplett 10y ago
    > Most of the logic behind git2-rs (as far as I know) is written in C. 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.