Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How memory safety CVEs differ between Rust and C/C++

kobzol.github.io

Post reply on HN
Print view View original

51–60 of 270 posts

Re: How memory safety CVEs differ between Rust and C/C++

#51

Post by bbippin »

khuey wrote: post #23
bbippin wrote: post #21

Earlier quoted context omitted.

The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.

> The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.

Perhaps. But what percentage of exploits are actually zero days versus, say, 10 days or 100 days?

Most exploited code probably exists in the application layer in a high-level, memory safe language. I would wager that but I don’t have time to cite ten papers on HN.

Re: How memory safety CVEs differ between Rust and C/C++

#53

Post by fluffybucktsnek »

chilljinx wrote: post #17
Groxx wrote: post #10

Earlier quoted context omitted.

I'm caught somewhere between interpreting this as "C is all we need. git gud" and "rust hurt me and I'm still mad" and I'm struggling to see any other option. It's an unfocused rant that seems keyed off "rust" and little else. In broad strokes it's correct, this stuff happens and it's hard to be correct all the time. But are you trying to make a point? Or just ranting? Also that linked issue was considered a CVE and…

[flagged]

No, they are asking for clarification.

Re: How memory safety CVEs differ between Rust and C/C++

#55

Post by sunshowers »

bbippin wrote: post #21
khuey wrote: post #12

Earlier quoted context omitted.

> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed] Google says memory safety issues are 75% of exploited zero days. ( https://security.googleblog.com/2024/10/safer-with-google-ad... )

The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.

Rust is a beautiful language. Gorgeous.

Re: How memory safety CVEs differ between Rust and C/C++

#56

Post by bbippin »

jabl wrote: post #48
bbippin wrote: post #21

Earlier quoted context omitted.

The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.

Rust and Ada are about equally safe, both have advantages and disadvantages. Perhaps you're thinking about SPARK ADA, but that's a different kettle of fish. It's a bit like saying you should program in C, because formal verification tool X generates C code hence C is safe.

Yeah SPARK ADA is what I meant :)

I think formal verification is the way to go with AI moving forward.

Re: How memory safety CVEs differ between Rust and C/C++

#57

Post by pengaru »

jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

"extreme pro level"

how old are you?

Re: How memory safety CVEs differ between Rust and C/C++

#58

Post by kllrnohj »

afdbcreid wrote: post #11
kllrnohj wrote: post #5

Earlier quoted context omitted.

> Nor if one of the soundness holes in the Rust programming language itself is encountered. imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.

You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.

No, that's exactly what I'm aware of, and is exactly the wrong behavior I'm talking about. "Sometimes crashes, sometimes two's compliment" are extremely different behaviors, and not meaningfully different from just saying it's UB. It should always panic, with no way to disable it. The wrap around in release mode is simply bad behavior. It can't be relied upon (because it panics in debug), and it's not useful behavior for nearly anyone's logic (wrap around almost never is logically correct behavior)

It lets Rust claim to be UB free without delivering the actual value of being UB free. You still can't rely on a given behavior because it doesn't have one behavior, it has two, and the two behaviors are wildly incompatible with each other.

Re: How memory safety CVEs differ between Rust and C/C++

#59

Post by wahern »

khuey wrote: post #12
jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed] Google says memory safety issues are 75% of exploited zero days. ( https://security.googleblog.com/2024/10/safer-with-google-ad... )

Most memory bugs in Chromium are in V8, either entirely in the JIT or at the boundary with C++. Rust wouldn't help here because the borrow checker can't see through these boundaries, and it's precisely this opacity where the developers also lose track of things.

Which isn't to say Rust wouldn't have caught many of the other memory safety issues, but 75% is horribly misleading.

Re: How memory safety CVEs differ between Rust and C/C++

#60

Post by steveklabnik »

kllrnohj wrote: post #58
afdbcreid wrote: post #11

Earlier quoted context omitted.

You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.

No, that's exactly what I'm aware of, and is exactly the wrong behavior I'm talking about. "Sometimes crashes, sometimes two's compliment" are extremely different behaviors, and not meaningfully different from just saying it's UB. It should always panic, with no way to disable it. The wrap around in release mode is simply bad behavior. It can't be relied upon (because it panics in debug), and it's not useful behavior…

> and not meaningfully different from just saying it's UB.

It is extremely meaningfully different, because the range of options of what can happen is bounded in one case (either two's compliment wrapping, or panic) and unbounded in the other case (literally anything is allowed to happen, including time travel).

This is "implementation defined behavior" in C and C++'s terms, not "undefined behavior."

Post reply on HN