←back to thread

Pitfalls of Safe Rust

(corrode.dev)
168 points pjmlp | 1 comments | 04 Apr 25 17:55 UTC | HN request time: 0.001s | source
Show context
nerdile ◴[06 Apr 25 17:56 UTC] No.43603402[source]▶
Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust.

A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."

replies(1): >>43603739 #
burakemir ◴[06 Apr 25 18:33 UTC] No.43603739[source]▶
It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors."

This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees.

It is subtle but not inconsistent that strong static checks ("safe Rust") may still leave the possibility of runtime errors. So there is a legitimate, useful broader notion of "safety" where Rust's static checking is not enough. That's a bit hard to express in a title - "correctness" is not bad, but maybe a bit too strong.

replies(5): >>43603865 #>>43603876 #>>43603929 #>>43604918 #>>43605986 #
quotemstr ◴[06 Apr 25 18:47 UTC] No.43603876[source]▶
Safe Rust code doesn't have accidental remote code execution. C++ often does. C++ people need to stop pretending that "safety" is some nebulous and ill-defined thing. Everyone, even C++ people, shows perfectly damn well what it means. C++ people are just miffed that Rust built it while they slept.
replies(2): >>43604117 #>>43604960 #
surajrmal ◴[06 Apr 25 19:16 UTC] No.43604117{3}[source]▶
Accidental remote code execution isn't limited to just memory safety bugs. I'm a huge rust fan but it's not good to oversell things. It's okay to be humble.
replies(1): >>43604340 #
dymk ◴[06 Apr 25 19:46 UTC] No.43604340{4}[source]▶
RCEs are almost exclusively due to buffer overruns, sure there are examples where that’s not the case but it’s not really an exaggeration or hyperbole when you’re comparing it to C/C++
replies(1): >>43604711 #
thayne ◴[06 Apr 25 20:30 UTC] No.43604711{5}[source]▶
Almost exclusively isn't the same as exclusively.

Notably the log4shell[1] vulnerability wasn't due to buffer overruns, and happened in a memory safe language.

[1]: https://en.m.wikipedia.org/wiki/Log4Shell

replies(2): >>43605126 #>>43605170 #
1. josephg ◴[06 Apr 25 21:31 UTC] No.43605126{6}[source]▶
The recent postgresql sql injection bug was similar. It happened because nobody was checking if a UTF8 string was valid. Postgres’s protections against sql injection assumed that whatever software passed it a query string had already checked that the string was valid UTF8 - but in some languages, this check was never being performed.

This sort of bug is still possible in rust. (Although this particular bug is probably impossible - since safe rust checks UTF8 string validity at the point of creation).

This is one article about it - there was a better write up somewhere but I can’t find it now: https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-po...

Rust’s static memory protection does still protect you against most RCE bugs. Most is not all. But that’s still a massive reduction in security vulnerabilities compared to C or C++.