Live data from Hacker News

Microsoft: 70 percent of all security bugs are memory safety issues

zdnet.com

71–80 of 180 posts

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#71
post #34

Earlier quoted context omitted.

And it has MORE reported CVEs than Windows: https://www.cvedetails.com/top-50-products.php?year=2018

It's also OSS and it is much easier to surface security bugs for Linux than for Windows. In my own research, I have attempted to send Microsoft security bugs only to be told they would be backlogged and reviewed later (which never happened to my knowledge).

> It's also OSS and it is much easier to surface security bugs for Linux than for Windows.

Shouldn't then the number of bugs decrease much faster, since they are easier to find? Unless they are introduced at even a greater rate than the ones in Windows.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#72
post #19
post #8

Earlier quoted context omitted.

There's a lot of memory safe languages out there that are great choices. Coming from a Microsoft statement, .Net is pretty neat. When your worst case latency/perf requirements don't allow you to have a GC, Rust is another great choice.

What about when you want a concurrency safe language? You can still have concurrency bugs, like race conditions in languages that are only memory safe.

Then use a concurrency safe language. There are plenty of slow ones (pass by copy) and even some supporting references into shared memory.

I would also emphasis the need for type safety and contracts.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#73
post #69

Earlier quoted context omitted.

sel4 shows that an endgame is possible wrt to memory safety, it's formally verfied to be memory safe. It's sitting at ~25 to 1, proof code to implementation code. I think you could probably get that down to 5 to 1 or so by treating a lot of the work they did as a library. The proof covers a full equivalence from abstract spec to machine code, and you could reuse a lot of that. Sort of how it's not fair to include the…

That's not an endgame if the resources required to block an attack are significantly greater than those required to make one. Moreover, verification is done with respect to specific properties that ensure no attacks of a particular kind . The more kinds of attacks you need to defend yourself from, the harder you need to work (and you will miss some). Not saying we're not making steps in the right direction, but no on…

It's an endgame wrt to memory safety (like I said). sel4 is memory safe. All the other mitigations like ASLR, canaries, etc are just hacks around the fact that proving memory safety of existing codebases is a Sisyphean task.

And getting down to 5/1 proof to implemention is within the realm of what unit tests you should be writing anyway, so it's not that much of an economic investment.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#75
Rust couldn't solve all of these bugs, but it certainly would have drastically reduced the total amount. The code would also be drastically easier to write and debug. C++17 is still a total mess to write, despite what Microsoft might tell you in their docs. Really doesn't make sense to me, outside of the sunk cost fallacy, why Microsoft isn't pivoting to Rust if they want to write C++.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#76
As an industry we should deprecate all unmanaged code. We've proven time and time again that even very professional and highly scrutinized unmanaged code can have critical data safety faults.

Yes, I understand this includes Linux, Windows, BSD, Darwin (iOS, MacOS, watchOS, etc), The Android Runtime, and lots of critical software that runs on top of those systems.

We have the tools to write very efficient managed code. Critical security flaws involving unauthorized access to data will continue to appear until we make the transition. The cost of these security flaws is likely to become more expensive than the cost of replacing the existing software. To make matters worse we are continuing to write more unmanaged code everyday.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#77

Rust couldn't solve all of these bugs, but it certainly would have drastically reduced the total amount. The code would also be drastically easier to write and debug. C++17 is still a total mess to write, despite what Microsoft might tell you in their docs. Really doesn't make sense to me, outside of the sunk cost fallacy, why Microsoft isn't pivoting to Rust if they want to write C++.

Microsoft probably has tons of internal libraries that are modified and shared between many different teams spanning multiple orgs.

I think a pivot like this is an incredibly complicated thing for a company like Microsoft to perform. It requires multiple years of planning from the ground up to port internal libraries and tooling, train engineers on Rust best practices.

Not to mention the tricky business of going around and hiring Rust developers at the scale MS needs. :)

I think, simply waking up one day and changing the language / frameworks / tools used by your company is a privilege only smaller companies and startups might enjoy.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#78
post #50
post #2

we should all be using Rust then :)

Right because Rust will prevent all the issues of Unsafe usage that an OS uses all the time ...

Say the same thing about seatbelts in a car. If you don’t plan to have accidents, why do you need seatbelts?

Car accidents, like mistakes in programming are a risk that has a likelyhood that is non-zero. A seatbelt might be a little bit annoying when things go well, but much less so when they don’t. Rust is there to stop you in most cases when you try to accidentally shot yourself into the leg, unless you deliberately without knowing what you are doing while yelling “hold my beer” (unsafe). And contrary to popular belief even in unsafe blocks many of Rust’s safety guarantees hold, just not all

If the net benefit of a ownership concept like Rust has it is high enough, this ahouls be an easy choice for rational actors to take. The odds are on Rust’s side here, because humans make mistakes and if Rust manages to allow productivity despite stopping certain classes of these mistakes, there will be a net benefit.

Just like with the seatbelt, there will be always those that don’t wear one for their very subjective reasons (e.g. because of edge cases where a seatbelt could trap you in a burning car, or because it is not cool, or because they hate the feeling and think accidents only happen to people who can’t drive).

I write Rust for a year now, and I constantly see bugs far better programmers made in say C++ where Rust just wouldn’t allow you to not handle it. E.g. Crashing your software by writing to a file that is locked by another process. In Rust this would mean the deliberate act of ignoring a Result, unwrapping it and moving on. You can ignore it, and Rust will crash, but you know exactly where you took that risk.

Things like these remove a lot of cognitive load from the programmer which can be put into more pressing topics

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#79

Rust couldn't solve all of these bugs, but it certainly would have drastically reduced the total amount. The code would also be drastically easier to write and debug. C++17 is still a total mess to write, despite what Microsoft might tell you in their docs. Really doesn't make sense to me, outside of the sunk cost fallacy, why Microsoft isn't pivoting to Rust if they want to write C++.

you could ask the same question for every os. And none choose Rust even the recent like fushia. BTW go ask Linus to switch to Rust I'm waiting for you there.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#80
post #70

Earlier quoted context omitted.

No, just use Rust...

Nonsense. Rust safeties are massively overhyped. Not enough memory safety (comparable to Java, which is similarily memory unsafe), no type safety (unsafe keyword), not enough concurrency safety (not deadlock free, need to manually set mutexes). While there do exist safe and fast languages, Rust is not one of them.

If we all wrote in languages as memory-safe as Java, almost all these security bugs would go away.

Is Rust guaranteed to be 100% memory-safe? No, there could always be bugs in the compiler and/or unsafe code. (Aside: it annoys me how people consider the presence of an unsafe keyword inherently less trustworthy than a non-verified compiler/runtime system, when there is really little difference between them.) Is it a huge improvement? Yes.

Post reply on HN