Conversation

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

@rustlang

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

373

674

Replying to

and

I like

but it doesn't seem that memory safe with a few CVEs under its belt in its standard library cvedetails.com/vulnerability-

Replying to

and

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.

Replying to

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.

Replying to

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

Replying to

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.

Replying to

and

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.

Replying to

and

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.

4:39 PM · Jul 17, 2019Twitter Web Client

Replying to

and

Storey that wasn't my intention. Thanks again for the clarification

Replying to

Code is going to have bugs. That's why it's important to write code in a memory safe language where those bugs aren't going to result in memory corruption exploitable for remote code execution. You're only demonstrating why it's useful and important with what you've said / shown.