4 ms·

>> spatial safety vulnerabilities represent 40% of in-the-wild memory safety exploits Rust advocates tend to turn stats like this into “40% of all security iss

>> spatial safety vulnerabilities represent 40% of in-the-wild memory safety exploits Rust advocates tend to turn stats like this into “40% of all security issues are memory safety”, which sounds very similar but is false.

kibwen 2y ago
> Rust advocates tend to turn stats like this into “40% of all security issues are memory safety”, which sounds very similar but is false. You're right that it's false. Historically it's been a much more damning 70% of vulnerabilities that were rooted in memory-unsafety. According to the Google Security Blog, in a post linked to from the OP: We’ll also share updated data on how the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages. [...] The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...
- andrewstuart 2y ago
  You’re still not getting the point. OWASPs top ten security vulnerabilities are not memory safety.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - pornel 2y ago
    Because most applications aren't written in C++. People don't write web apps in C++, because they would have to deal with memory safety issues in addition to all the other issues related to auth, injections, etc.
  - jerf 2y ago
    So, maybe you can answer a question I've really had a hard time understanding, that I've posted about before: https://news.ycombinator.com/item?id=39542875 https://news.ycombinator.com/item?id=39542875 Why are you offended at the idea that languages should be memory safe by default? What code are you writing that you constantly need memory unsafety, constantly available, without being able to write any sort of "unsafe" keyword? Who cares about whether or not it's the #1 problem in OWASP when it's clearly and undeniably been a massive problem for decades? It is sufficient, after all, that it crashes a program or produces incorrect results for it to be a problem worth pursuing, but it is also extremely well known to produce massive security vulnerabilities regardless of what some list says. Why is this a hill you are willing to die on? What are you getting out of it? Is your programming life going to be easier? Are you better off when debugging something to not be able to just know that it's not a memory safety problem, and thus to still have to consider it? What actual engineering benefit do those rare few of you who seem to be crusading against memory safety fear disappearing? When I got into programming in the late 1990s, I was there to catch the last few holdouts of the "everyone should just write in assembler" opinion. I at least understood their arguments around performance and efficiency, and I understood their arguments around "not needing high level languages" even though I disagree with them both then and now. I think on the net they were wrong, but they did have some legitimate benefits to argue on their side, even if they were already outweighed by the costs then and even more so outweighed today. But I don't get what you folk furious about memory safety are looking for. "Using" memory safety is already an invalid program. It's already pretty much automatically a bug, if not worse. You're not losing anything to simply have it, you're not gaining anything except bugs and sharp corners insisting on it. And when you absolutely, positively need it, which I'd call "exceptionally rare but definitely non-zero", it's still there in one form or another of "unsafe". I don't see any benefits at all. (And let me reiterate and forstall the usual, memory safety does not mean "Rust". Memory safety is every major language on the market today except C and C++.)
    - addaon 2y ago
      > Why are you offended at the idea that languages should be memory safe by default? Why are you okay with languages that are not overflow-safe, or unit-safe, or infinite-loop-safe, or safe against bit flips? Memory safety violations are a major chunk of bugs. Writing code to avoid them is about as hard as writing code to avoid other major classes of bugs. In either case, it’s failable. Static analysis and testing then gives confidence that the system is safe, by multiple metrics. Memory safety isn’t special enough to demand a different approach here — quality code requires a coherent approach to quality across multiple bug classes.
- deleted 2y ago
  [deleted]
IshKebab 2y ago
I think you're forgetting about temporal safety (use after free). Presumably that brings it up to the 70% of security issues being related to memory safety, which many studies have shown - remarkably consistently.
pjmlp 2y ago
First of all it is 70%, and secondly even if people like to FUD Rust, it is all security advocates that state this, including those of us that would like a better attitude towards safety in C++ world. We got too many C refugees that spoiled the soup.
- andrewstuart 2y ago
  The top security issues do not relate to memory safety. Rust advocates like to muddy the water and make it sound like memory safety is the biggest issue in security. It isn’t.
  - pjmlp 2y ago
    You mean advocates like Microsoft Security Response Center and Google Project Zero? Or advocates like NSA and FBI? Security FUD, name calling Rust any time someone raises security issues, is quite impressive.

kibwen 2y ago

> Rust advocates tend to turn stats like this into “40% of all security issues are memory safety”, which sounds very similar but is false. You're right that it's false. Historically it's been a much more damning 70% of vulnerabilities that were rooted in memory-unsafety. According to the Google Security Blog, in a post linked to from the OP: We’ll also share updated data on how the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages. [...] The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...

andrewstuart 2y ago
You’re still not getting the point. OWASPs top ten security vulnerabilities are not memory safety.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- pornel 2y ago
  Because most applications aren't written in C++. People don't write web apps in C++, because they would have to deal with memory safety issues in addition to all the other issues related to auth, injections, etc.
- jerf 2y ago
  So, maybe you can answer a question I've really had a hard time understanding, that I've posted about before: https://news.ycombinator.com/item?id=39542875 https://news.ycombinator.com/item?id=39542875 Why are you offended at the idea that languages should be memory safe by default? What code are you writing that you constantly need memory unsafety, constantly available, without being able to write any sort of "unsafe" keyword? Who cares about whether or not it's the #1 problem in OWASP when it's clearly and undeniably been a massive problem for decades? It is sufficient, after all, that it crashes a program or produces incorrect results for it to be a problem worth pursuing, but it is also extremely well known to produce massive security vulnerabilities regardless of what some list says. Why is this a hill you are willing to die on? What are you getting out of it? Is your programming life going to be easier? Are you better off when debugging something to not be able to just know that it's not a memory safety problem, and thus to still have to consider it? What actual engineering benefit do those rare few of you who seem to be crusading against memory safety fear disappearing? When I got into programming in the late 1990s, I was there to catch the last few holdouts of the "everyone should just write in assembler" opinion. I at least understood their arguments around performance and efficiency, and I understood their arguments around "not needing high level languages" even though I disagree with them both then and now. I think on the net they were wrong, but they did have some legitimate benefits to argue on their side, even if they were already outweighed by the costs then and even more so outweighed today. But I don't get what you folk furious about memory safety are looking for. "Using" memory safety is already an invalid program. It's already pretty much automatically a bug, if not worse. You're not losing anything to simply have it, you're not gaining anything except bugs and sharp corners insisting on it. And when you absolutely, positively need it, which I'd call "exceptionally rare but definitely non-zero", it's still there in one form or another of "unsafe". I don't see any benefits at all. (And let me reiterate and forstall the usual, memory safety does not mean "Rust". Memory safety is every major language on the market today except C and C++.)
  - addaon 2y ago
    > Why are you offended at the idea that languages should be memory safe by default? Why are you okay with languages that are not overflow-safe, or unit-safe, or infinite-loop-safe, or safe against bit flips? Memory safety violations are a major chunk of bugs. Writing code to avoid them is about as hard as writing code to avoid other major classes of bugs. In either case, it’s failable. Static analysis and testing then gives confidence that the system is safe, by multiple metrics. Memory safety isn’t special enough to demand a different approach here — quality code requires a coherent approach to quality across multiple bug classes.
deleted 2y ago
[deleted]

IshKebab 2y ago

I think you're forgetting about temporal safety (use after free). Presumably that brings it up to the 70% of security issues being related to memory safety, which many studies have shown - remarkably consistently.

pjmlp 2y ago

First of all it is 70%, and secondly even if people like to FUD Rust, it is all security advocates that state this, including those of us that would like a better attitude towards safety in C++ world. We got too many C refugees that spoiled the soup.

andrewstuart 2y ago
The top security issues do not relate to memory safety. Rust advocates like to muddy the water and make it sound like memory safety is the biggest issue in security. It isn’t.
- pjmlp 2y ago
  You mean advocates like Microsoft Security Response Center and Google Project Zero? Or advocates like NSA and FBI? Security FUD, name calling Rust any time someone raises security issues, is quite impressive.