[quotemstr]

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.

[surajrmal]

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.

[dymk]

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++

[thayne]

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

[josephg]

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++.

[FreakLegion]

In fact "exclusively" doesn't belong in the statement at all. A very small number of successful RCE attacks use exploits at all, and of those, most target (often simple command) injection vulnerabilities like Log4Shell.

If you think back to the big breaches over the last five years, though -- SolarWinds, Colonial Pipeline, Uber, Okta (and through them Cloudflare), Change Healthcare, etc. -- all of these were basic account takeovers.

To the extent that anyone has to choose between investing in "safe" code and investing in IT hygiene, the correct answer today is IT hygiene.

[surajrmal]

Can you back up your 'very small number " with some data? I don't think it lines up with my own experience here. It's really not an either or matter. Good security requires a multifaceted approach. Memory safety is definitely a worthwhile investment.

[FreakLegion]

What do you count as data? I can keep naming big breaches that didn't involve exploits, like the Caesars and MGM ransomware attacks, or Russia getting deep into Microsoft. There aren't good public data sets, though.

As an example of a bad data set for this conversation, the vast majority of published CVEs have never been used by an attacker. CISA's KEVs give a rough gauge of this, with a little north of 1300 since 2021, and that includes older CVEs that are still in use, like EternalBlue. Some people point to the cardinality of CVE databases as evidence of something, but that doesn't hold up to scrutiny of actual attacks. And this is all before filtering down to memory safety RCE CVEs.

Probably the closest thing to a usable data set here would be reports from incident response teams like Verizon's, but their data is of course heavily biased towards the kinds of incidents that require calling in incident response teams. Last year they tagged something like 15% of breaches as using exploits, and even that is a wild overestimate.

> Memory safety is definitely a worthwhile investment.

In a vacuum, sure, but Python, Java, Go, C#, and most other popular languages are already memory safe. How much software is actively being written in unsafe languages? Back in atmosphere, there's way more value in first making sure all of your VPNs have MFA enabled, nobody's using weak or pwned passwords, employee accounts are deactivated when they leave the company, your help desk has processes to prevent being social engineered, and so on.

[yjftsjthsd-h]

Research I've seen seems to say that 70-80% of vulnerabilities come from memory safety problems[0]. Eliminating those is of course a huge improvement, but is rust doing something to kill the other 20-30%? Or is there something about RCE that makes it the exclusive domain of memory safety problems?

[0] For some reason I'm having trouble finding primary sources, but it's at least referenced in ex. https://security.googleblog.com/2024/09/eliminating-memory-s...

[Xylakant]

Rust also provides guarantees that goe beyond mere memory safety. You get data-race safety as well, which avoids certain kinds of concurrency issues. You also get type-safety which is a step up when it comes to parsing untrusted input, at least compared to C for example. If untrusted inout can be parsed into your expected type system, it's more likely to not cause harm by confusing the program about what's in the variables. Rust doesn't straight up eliminate all source of error, but it makes major strides forward in areas that go beying mere memory safety.