Audit flate2
Shnatsel opened this issue · comments
https://crates.io/crates/flate2
Frontend to a number of DEFLATE compression/decompression libraries: zlib, miniz and miniz_oxide. 11,000 downloads/day, exposed to untrusted data from the network through reqwest 😱
Following the work done by @oyvindln as part of #2, when using the Rust backend (miniz_oxide) it's already almost 100% safe. The only remaining unsafety in that path is passing a slice of uninitialized memory to be filled: https://github.com/alexcrichton/flate2-rs/blob/537fb77132a15b772fcc9c35a4c8c679d40aedf7/src/mem.rs#L317-L323
The outer function accepts the output buffer as &mut Vec<u8>, converts it to a slice internally and passes the slice as output buffer to the backend. If the backend does not overwrite the entire slice, this can become an exploitable security vulnerability.
Exposure of uninitialized memory can be easily avoided by passing the &mut Vec<u8> to miniz_oxide and decoding to it instead of decoding to a slice. This will likely require some additions to miniz_oxide APIs as well.
Opened an issue on flate2 project about the above: rust-lang/flate2-rs#220
MaybeUninit<T> aside, flate2 appears to be fully processed. The last two unsafe blocks cannot be killed off without losing performance - it would require a fixed-capacity Vec-like view of memory. I'll need to write an RFC for one at some point.
@Shnatsel are we tracking the "if we had {X} we could remove unsafe" somewhere to have some ability to quantify relative value of different priorities?
Sort of? We have #34 for now, not sure if we need a more permanent place for collecting these.