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

231–240 of 270 posts

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

#231

Post by drysine »

tialaramex wrote: post #205
drysine wrote: post #179

Earlier quoted context omitted.

>ColdString and CompactString, which are way better than what's provided in C++ Could you elaborate on that?

Sure, to simplify lets assume a 64-bit CPU (this all works for 32-bit but that's less common these days and the actual numbers are different) C++ std::string can contain up to 15 (other popular implementations) or 22 bytes (libc++ from Clang) of inline text, and the data structure itself is either 24 bytes (Clang again) or 32 bytes of storage. Here's Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20240510-0…

Thanks!

How do CompactString/ColdString compare to std::string implementations performance-wise? From the looks of it, they must be somewhat slower than C++ strings

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

#232

Post by jurschreuder »

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

Google Chromium but not it's not even in the top 10 of vulnerabilities in Github

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

#233

Post by jurschreuder »

kalaksi wrote: post #20
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... )

And at least in Chromium project, half of those memory safety issues are use-after-free: https://www.chromium.org/Home/chromium-security/memory-safet...

Then you're looking at very old data, recent top 500 CVE's 100% of the use-after-free exploits where escalation to Admin on Windows.

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

#234

Post by jurschreuder »

wahern wrote: post #59
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... )

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.

In Chromium which is the condom of the internet, already millions of developer hours of the most highly paid developers have spent their days trying to make it water tight. This is not your average software project.

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

#235

Post by jurschreuder »

afdbcreid wrote: post #26
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... )

My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language. Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.

PHP is garbage collected for reference. So rewriting wordpress plugins in Rust would not make them more secure but rewriting HAProxy or Nginx would? It's delusional.

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

#236

Post by jurschreuder »

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.

In highly specific programs like browser sandboxes. Not in things like wordpress plugins or nodejs servers.

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

#237

Post by jurschreuder »

jeffbee wrote: post #16
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…

Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid st…

You can also write inline assembly in C++ and then it's not safe.

But no developers working on projects that have been so ultimately battle tested that only memory safety issues remain do that. Professional C++ developers use RAII and containers. If you use raw pointers or raw arrays in C++ you will get 200 code reviewers lecturing you. You will never be able to for long.

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

#238

Post by jurschreuder »

slopinthebag wrote: post #6
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…

Any sources for these numbers?

Yes all of them have sources.

Look for example top 500 CVEs of this year (after many fixes in C++, not right when the 70% memory issues in Chrome came out).

Look at top 10 CVE github 2025 (zero memory related does not make it).

Look at that sudo-rs was not allowed in Ubuntu because it's not as safe (way worst track record) than the C version, almost all is input sanitation.

Look at wordpress plugins hacks, all PHP all memory safe language. Compare that to HAProxy and Nginx (C).

Etc.

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

#239

Post by jamesfinlayson »

jiggawatts wrote: post #141
jamesfinlayson wrote: post #114

Earlier quoted context omitted.

Yep, at work my team's vulnerability dashboard constantly shows hundreds of critical and high vulnerabilities. Fortunately/unfortunately, 99% of these issues are for Javascript dependencies in websites that are not server-side rendered... so we look bad, even though we have no exposure to most of these vulnerabilities.

Just yesterday I made myself a NuGet package analyzer tool -- okay fine, I vibe coded it -- that has convenient buttons for filtering out client-side packages, test projects, and dev-time tooling like Aspire.NET.

Unfortunately GitLab has no such useful features.

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

#240

Post by fragmede »

jurschreuder wrote: post #235
afdbcreid wrote: post #26

Earlier quoted context omitted.

My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language. Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.

PHP is garbage collected for reference. So rewriting wordpress plugins in Rust would not make them more secure but rewriting HAProxy or Nginx would? It's delusional.

If the class of bugs WordPress has is different from the class of bugs HAProxy/Nginx, eg SQl injection vs buffer overflow, then why is a different mehtoyof fixing "delusional"?
Post reply on HN