I find it funny that now fuzzers are being written in rust, as if that translates to better quality bugs being found.
It looks to me like the effort would have been better spent writing a decoder in rust. AFAIK Mozilla moved the mp4 (that's the container format often used around h264) parser in firefox to rust, but their h264 decoder is from ffmpeg (?). In the end the h264 will most likely be decoded in the gpu using closed source code by the hardware vendor.
Kudos to the team for doing smart fuzzing instead of just throwing garbage. Most fuzzing projects spend much less brain power, and usually get worse results.
The mp4 demuxer is indeed in Rust [0], and runs in the content process (= the process in which the web page is loaded).
We don't have a h264 decoder in our source tree, we use the platform's decoder (because of patents). It's very often in a separate, dedicated process, and when it's not, it's in the GPU process, because when hardware accelerated decoders are used, they're using more or less the same resources as the rendering code.
Those other processes with the tightest sandbox possible (per process type, per platform, etc.), and don't have access to the web page.
On Linux, the platform decoder we're using is `libavcodec` from FFmpeg, but that's still in a separate process with a tight sandbox.
We're also doing something interesting, which is compiling libraries to WASM and then back to native code to get memory safety [1]. This is used when performance isn't critical (unlike codecs, so, e.g. a demuxer that we don't want to rewrite in Rust).
> now fuzzers are being written in rust, as if that translates to better quality bugs being found.
I'm not sure if you're being facetious, but this is a classic straw man fallacy[0]: you've constructed a nonsensical motivation for the authors' use of Rust, then argued against that motivation.
There is superficial similarity between (1) "the authors wrote the fuzzer in Rust" and (2) "the authors wrote the fuzzer in Rust because it translates to better-quality bug findings", but the paper's authors did not claim (2), nor would any reasonable person claim (2).
More likely is that Rust is a useful language for authoring fuzzers because it is fast and supports modern abstractions while eliminating multiple troublesome categories of bugs. Fast performance, zero-cost abstractions, automatic memory management, and concurrency safety are useful language properties regardless of their relevance to security bugs.
A Rust decoder was something discussed at the start, which is why we chose the language. As research goes, we primarily focused on just the H.264 syntax elements.
The Chromium folks are working on a Rust crate called cros-codecs [1] for VP8, VP9, and H.264 parameter set parsing, with VAAPI as a back-end.
> I find it funny that now fuzzers are being written in rust, as if that translates to better quality bugs being found.
I can't find any such claim in the article. It says the tools are written in Rust and Python. I don't see any claims that fuzzing with a Rust-based fuzzer produces "better quality bugs". That seems to be your own assumptions projected on to the authors?
It's more likely that the authors wrote the tools in languages they're comfortable working with. It's not surprising that security researchers would be familiar with writing Rust.
You seem to be imputing motivation for using Rust, then criticizing them for making your assumption. If they had written a fuzzer in python, would you assume they used python because they had the mistaken idea that a slower program would produce better results?
It seems like a much more likely explanation is they know Rust well and it is their tool of choice. Another possibility is that a good fuzzer is non-trivial and they appreciate the compile-time checks offered by the language to avoid an entire class of errors.
It looks to me like the effort would have been better spent writing a decoder in rust. AFAIK Mozilla moved the mp4 (that's the container format often used around h264) parser in firefox to rust, but their h264 decoder is from ffmpeg (?). In the end the h264 will most likely be decoded in the gpu using closed source code by the hardware vendor.
Kudos to the team for doing smart fuzzing instead of just throwing garbage. Most fuzzing projects spend much less brain power, and usually get worse results.