Hacker News Reader

Comment by onei | Hacker News Reader

Not being aware of how vulnerabilities are detected and despite being a big fan of Rust, I wonder if there are other variables that drive down the ability to find bugs in the short term. If a researcher is only familiar with C and C++, is it possible that they're just ill equipped to find similar bugs in Rust?

View on HN

Rust programs can have vulnerabilities, but thankfully the fuzzer scene is well developed. Recently a memory safety bug was found in a Rust library (that used unsafe) and it turns out the original C++ implementation had it too. So here, fuzzing the Rust rewrite led to improvements in the original C++ library. I guess it's because there is higher interest in increasing the safety of Rust programs.

https://dwrensha.github.io/capnproto-rust/2022/11/30/out_of_...

,,it's because there is higher interest in increasing the safety of Rust programs''

Another explanation is that fuzzing is generally expensive and it's easier to focus on unsafe parts of Rust programs than whole C++ programs.

There's definitely a learning curve for looking for vulns in Rust vs C/C++, especially compared to C. Exploitation in particular will be the trickier part, imo, since it requires not just understanding the vuln but also the context and reachability.

That said, there are a ton of ways that auditing for vulnerabilities is just as easy or way easier. In particular, most tooling for C/C++ can be applied to rust - fuzzers and sanitizers, for example. Additionally, one only has to "grep for unsafe" and work from there to find Rust vulns, which largely amounts to "what are the assertions for this unsafe block, are they complete, are they held?".

Not only that, they are also comparing new code with pretty old code.

They're also explicitly tracking new code by language, and talking about memory safety vulnerabilities per year, and they also link to [1] which talks about how most memory safety bugs they get are in new code.

Most of the graphs here are about new code.

[1]: https://security.googleblog.com/2021/04/rust-in-android-plat...

It's also useful to look at the "rate of bugs per line of new code" because even stablished, long stable projects have code churn. Rare is the project that is unchancged, frozen in bakelite, and any mild refactor can introduce regressions or affect relied upon implicit invariants.

Reply on news.ycombinator.com