Live data from Hacker News

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

zdnet.com

61–70 of 180 posts

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

#61

To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system. ``` Is all we can hope for in the security game a seri…

> Is there an end to this race?

If there is, it'll be a combination of two things.

One is you make things simple enough that finding the bugs is more realistic. WireGuard, not OpenSSL.

The other is that you make things modular, and once you have one of the modules right, you mostly leave it alone. Many people still use djbdns and qmail for a reason, and it's not the pace of new feature support.

These are trade offs. They do have costs. But it has proven to be more effective.

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

#63

Earlier quoted context omitted.

This paper's an interesting read, about writing an OS in Go: The benefits and costs of writing a POSIX kernel in a high-level language https://www.usenix.org/conference/osdi18/presentation/cutler

Not that Cutler, phew.

He would never write a (mainly) Posix kernel ;)

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

#64
post #34

Linux is also written in C.

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

Maybe because more people can report them? With Windows you'll be lucky if Microsoft doesn't outright deny their existence.

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

#65
post #58

Earlier quoted context omitted.

I wouldn't be surprised if it's easier to rewrite the kernel than to rewrite Office.

Why is that?

It is probably easier to figure out what it should be doing. With Office, sometimes you just have to line break like Word 97 (I am not making this up, it was a bad example of the so-called open format "OOXML"), which is much easier when you can just call the original Word 97 code, bugs and all.

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

#66
post #3
post #2

we should all be using Rust then :)

I knew this comment was coming :)))

It IS why Mozilla sponsored the language. The early "why Rust" presentations had a stat that (paraphrasing) 50% of Mozilla security bugs would have been prevented by the borrow checker.

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

#67
post #58

Earlier quoted context omitted.

I wouldn't be surprised if it's easier to rewrite the kernel than to rewrite Office.

Why is that?

Office is somewhere around an order of magnitude of so more code, everything I've heard is that it's nightmare fuel levels of legacy code that defies even refactoring within the same language, and has a bad habit of slurping up binary formats and doing crazy internal YOLO pointer chasing.

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

#68

To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system. ``` Is all we can hope for in the security game a seri…

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…

Nope, sel4 is unsafe against modern Spectre/Meltdown attacks. Only Fiasco was recently made safe against these.

Secondly, Microsoft's own SecureMemZero is insecure against those attacks. It only applies a trivial compiler barrier, but no memory barrier, so you cannot use it to securely delete sensitive memory.

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

#69

To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system. ``` Is all we can hope for in the security game a seri…

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 one thinks it's an endgame.

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

#70
post #16

Earlier quoted context omitted.

Security is an arms race, in a quite literal sense of the term. Arms races don't really ever end, except for truces/treaties or total victory.

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.
Post reply on HN