What if you could eliminate a common class of vulnerabilities by changing the language you used? MSRC is publishing a series on why Microsoft is looking at for memory-safe development and why we think you should too. See the first post here: msrc-blog.microsoft.com/2019/07/16/a-p
Conversation
I like but it doesn't seem that memory safe with a few CVEs under its belt in its standard library
cvedetails.com/vulnerability-
1
1
1
Those aren't bugs in code written in memory safe Rust. Those are bugs in low-level unsafe code building the safe abstractions. No one is claiming the Rust compiler and standard library are completely free of bugs. That's not what it means for it to be a memory safe language.
1
1
9
If you look at the details for those bugs, you'll see that these are soundness holes in APIs that are supposed to be safe. For these bugs to actually be exploitable, there would need to be code not just triggering the soundness holes, but in a way that exposes it to an attacker.
1
6
Those bugs demonstrate the need for memory safe languages. They're occurring in the memory unsafe dialect of Rust requiring explicit unsafe blocks and functions. It's important to minimize that trusted memory unsafe code which is pretty much the entire point of the language...
1
6
Rust's standard library, runtime and compiler are written in Rust rather than C. This requires the language to support an unsafe dialect for building the safe abstractions used in the safe language. It's not a surprise that code in a memory unsafe language has memory safety bugs.
Thanks for that explanation. I not saying that rust is an insecure language at all. Just bringing up that it has bugs too like any other language.
1
1
Again, no one has claimed that the Rust compiler and standard library are completely free of bugs. Your statement was that it doesn't seem very memory safe based on pointing to a few of the implementation bugs, i.e. you made a misleading statement based on misrepresenting facts.
2
1
6
Show replies