Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

zdnet.com

Post reply on HN
Print view View original

161–170 of 180 posts

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

#161

Post by Someone1234 »

m0zg wrote: post #134
Someone1234 wrote: post #110

Earlier quoted context omitted.

> Midori, as cool as it was, was Microsoft's "no output division" Considering you have absolutely no proof of that it seems rather disrespectful to act like that's a fact rather than your supposition.

It always cracks me up when people demand "proof" of something like this. I mean, I know some of the people from there from way back, and the project was eventually canceled, so there literally was "no output". And they had pretty much complete carte blanche on everything and could bikeshed over the most inane and inconsequential things for months on end. It was a fun "job" while it lasted, though.

Now I'm starting to wonder if you even read the "No Output" letter and understand its implication? You essentially called a bunch of Microsoft employees productivity drains on the rest of the company.

The fact that you think a cancelled project means it is the same as DEC's "No Output" team likely means you don't understand what the "No Output" team even was at DEC or the implication for the people within it.

You absolutely do need to present proof of what you're saying, because it is a serious charge for both Microsoft and those employees alike.

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

#162

Post by throwupaway123 »

reallydude wrote: post #33
skyde wrote: post #2

we should all be using Rust then :)

> Microsoft: 70 percent of OUR security bugs are memory safety issues Fixed the title. This is not an analysis about general software errors.

Every project with millions of lines of C or C++ is going to be around the same, Firefox is over 50% as well.

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

#163

Post by monocasa »

nineteen999 wrote: post #158
monocasa wrote: post #67

Earlier quoted context omitted.

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.

> and has a bad habit of slurping up binary formats and doing crazy internal YOLO pointer chasing. ... you know that this about what 9/10th's of an operating systems device driver code look like, right?

Not from externally imported data. That's a privilege escalation vulnerability when the kernel pulls that crap.

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

#164

Post by Dahoon »

pjmlp wrote: post #145
hk-mars wrote: post #133

90% of these memory bugs of MS are related to C++, bad designers I think; C is still good in low level of system hack.

Google thinks otherwise, hence Linux Kernel Self Preservation Project.

Kernel Self Protection Project (:

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

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

#165

Post by monocasa »

pron wrote: post #149
monocasa wrote: post #73

Earlier quoted context omitted.

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.

I am not at all against formal verification. In fact, I evangelize it and use it myself quite a bit. But it is important to understand that it is very, very far from being a miracle cure. All software proofs prove correctness of specific theorems about a program given certain axioms. Those axioms must include, at the very least, the conformance of the hardware to some specification. But hardware can, at best, conform…

> However much the effort of a similar technique can be reduced, it doesn't scale linearly with the size of the program

[citation needed]

Sure, you can write an arbitrary application where that's true, but AFAIK it doesn't have to be. IMO, sel4's really cool part isn't that it just was formally verified, but it's total design specifically for verifiability.

The argument reminds me of all the people in the late 90s talking about how unit tests would never take off because they tried to introduce it in their legacy spaghetti codebase, and it wasn't amenable to testing.

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

#166

Post by max76 »

drainyard wrote: post #136
max76 wrote: post #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…

I would much rather switch to a compiler-restricted memory safe unmanaged alternative such as Rust, before I throw out performance for safety completely. A lot of applications, such as video games, don't require the type of security others do, but require performance to a much higher degree. Rust is a good middle-ground, since it does have some compile-time issues at the moment still which are getting better. But it…

I'd agree that Rust would be a great alternative to C/C++ in performance critical applications.

Video games often have direct or indirect access to personal and credit card data. To double the issue of memory safety some popular video games encourage user generated content to be consumed in game. While less critical than an http server I still think it would benefit. Unity runs game logic in managed c#. Opengl is still wirrten in C.

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

#167

Post by Dahoon »

sanxiyn wrote: post #116
21 wrote: post #71

Earlier quoted context omitted.

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

You are right. One current estimate is that Linux is introducing security bugs at a rate faster than they are fixed.

New and better tools are finding bugs in old code, so it isn't really that more and more bugs get into new code:

"But, your editor wondered, could we be doing more than we are? The response your editor got was, in essence, that the bulk of the holes being disclosed were ancient vulnerabilities which were being discovered by new static analysis tools. In other words, we are fixing security problems faster than we are creating them. "

https://lwn.net/Articles/410606/

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

#168

Post by fxfan »

nineteen999 wrote: post #153
pjmlp wrote: post #146

Earlier quoted context omitted.

How do you think Office 365 works?

A bunch of tiny pjmlp's running around in a hamster wheel providing electricity maybe? Are you suggesting the post I linked above from someone claiming to be an engineer on Office is inaccurate? It may be well be, but it sounds more plausible and supportable than whatever question it is you seem to be posing. If you have evidence to suggest that Office365 is written in C# these days I'd like to see it please, because…

Whoa, easy with the personal attack there.

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

#169

Post by pjmlp »

Dahoon wrote: post #164
pjmlp wrote: post #145

Earlier quoted context omitted.

Google thinks otherwise, hence Linux Kernel Self Preservation Project.

Kernel Self Protection Project (: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

I always get it wrong. :)

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

#170

Post by pron »

monocasa wrote: post #165
pron wrote: post #149

Earlier quoted context omitted.

I am not at all against formal verification. In fact, I evangelize it and use it myself quite a bit. But it is important to understand that it is very, very far from being a miracle cure. All software proofs prove correctness of specific theorems about a program given certain axioms. Those axioms must include, at the very least, the conformance of the hardware to some specification. But hardware can, at best, conform…

> However much the effort of a similar technique can be reduced, it doesn't scale linearly with the size of the program [citation needed] Sure, you can write an arbitrary application where that's true, but AFAIK it doesn't have to be. IMO, sel4's really cool part isn't that it just was formally verified, but it's total design specifically for verifiability. The argument reminds me of all the people in the late 90s ta…

> [citation needed]

Watch Xavier Leroy's talks.

> IMO, sel4's really cool part isn't that it just was formally verified, but it's total design specifically for verifiability.

Well, they were very selective with their algorithm choices, so that only very simple algorithms were used. Whether that's cool or an unaffordable restriction depends on your perspective.

> The argument reminds me of all the people in the late 90s talking about how unit tests would never take off because they tried to introduce it in their legacy spaghetti codebase, and it wasn't amenable to testing.

Except that I've been both practicing and evangelizing formal methods for some years now. I argue in favor of using them, not against, but as someone with some experience in that field I want to make sure people's expectations are reasonable. Unreasonable expectations all but killed formal methods once before.

Post reply on HN