>> 70% of security defects in memory-safe languages are probably also memory safety problems.
> That doesn't make any sense at all
I'm sure it's not true—70% is way too high—but the real number isn't 0% as you might expect.
In particular, (most? all?) non-Rust languages that claim or appear to be memory-safe can have data races. In Go for example, those can be exploitable. [1]
And Rust is memory-safe...in safe code, with a bug-free compiler. Real programs have some unsafe code in their transitive dependencies and are compiled with the real, buggy compiler. [2] The percentage of security bugs in Rust code that are due to memory safety problems is more than 0%.
Not to say they don’t exist or haven’t been reported, but many of the unsound issues on github for Rust don’t seem to hold water.
They all seem to misbehave on a single nightly build, affect only a very narrow and unsupported target group, be related to a bug in a unsupported release of LLVM, or simply aren’t reproducible. I think the percentage of security bugs in Rust related to memory safety, based off that list, is _effectively_ 0%. I can’t find an issue in the list that seems like it would impact Rust programs that people write today or on targets that people deploy Rust code where memory safety matters.
That probably reflects the higher standards in the Rust ecosystem. I remember when there was a big issue about “Pin is unsound”. Judging by how seriously people were taking it, it seemed like it was the next Heartbleed. Turned out that it was unsound only in a very contrived example.
I don't think soundness/security flaws due to compiler bugs are common, but they qualitatively can happen. I think that might be getting forgotten when folks are puzzled about the idea of memory safety bugs in memory-safe languages.
And there are memory-safety bugs on the CPU level, as we had to learn. However, "safe" languages cut the risk of a memory-safety related bug down by orders of magnitudes, in most cases to practically zero, as the Go example require quite an effort to create the situation. You don't end up in such a situation just by a programmers or logic error, and thats what the memory bugs are about.
I would not even say that Rust (or any other language) is or can be perfectly safe in "safe" code even with a bug-free compiler.
It is possible to access unallocated memory in 100% "safe" Rust, because what memory that is allocated and not depends on the programmer's intent.
Allocated memory is memory that you intend to use.
If I make an array of 3 integers that are not supposed to be used yet but I accidentaly access one of them, then that is a memory-safety bug because I accessed unallocated memory.
The functions that languages provide to "allocate" memory don't define what allocating memory means.
They just provide a tool that you can use to keep track of what memory you are using.
What memory is allocated or not is relative and there are multiple levels of allocation.
If we zoom out a bit we can even call C a memory-safe language because all memory accesses in C must be to allocated memory and the ones that are not will kill the process
(allocated here as in allocated to the process by the operating system).
No, I'm just saying that what memory is allocated (as in the language) is not necessarily the same as the memory that is allocated as in your intentions.
It's possible to allocate (as in language) an array that is longer than what you really need,
and when you are done using some of the memory in that array you might not want to call any free/realloc functions in order to make the program faster.
So instead you might want to just remember that the memory is unallocated (as in intentions) even if it's still allocated (as in language).
And now there is a disagreement between you and the language on what memory is allocated.
No "memory-safe" language can make sure you don't accidently use memory unintentionally.
With that said, languages like Rust really give you helpful tools to minimize the unintentional memory accesses.
My guess is that the commenter is trying to say that security issues safe languages are probably a result of calling into unsafe code or a bugs in a runtime written in an unsafe language.
