Microsoft: 70 percent of all security bugs are memory safety issues • Hacker News Board

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

#101

Post by chiph » Tue, Feb 12, 2019, 1:10 AM UTC

m0zg wrote: post #60

Someone1234 wrote: post #4

Just a painful reminder that they scrapped Midori[0] their managed Operating System based on Microsoft Research's Singularity project[1]. Even if it only replaced Windows LTSB/Embedded, I'd still prefer an ATM, checkout, or gas station terminal I was using was running on managed code. Doubly so for the next generation of Nuclear Powered submarines[3]. Plus between virtualisation and silo-ed software management ("Apps…

Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.b... for context). It existed so that very senior engineers wouldn't go elsewhere and cause trouble for Microsoft. It had fullfilled its purpose in that regard. I strongly suspect that some of Google's more ambitious endeavors serve the same purpose.

Were they placed there because of negative productivity (as implied from the DEC memo), or so they wouldn't become someone else's competitive advantage? (even at the cost of not letting their unvested shares return to the pool when they left)

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

#102

Post by phkahler » Tue, Feb 12, 2019, 1:12 AM UTC

rurban wrote: post #70

raymond_goo wrote: post #39

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.

>> Nonsense. Rust safeties are massively overhyped.

No. They are not. You obviously have not done your homework on the subject.

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

#103

Post by jodrellblank » Tue, Feb 12, 2019, 1:13 AM UTC

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…

The cost of these security flaws is likely to become more expensive than the cost of replacing the existing software.

Expensive to whom? When was Microsoft or RedHat or Oracle or the FreeBSD foundation last fined or sued because of a security flaw - an unmanaged memory one, specifically?

When was a random company or developer fined or sued for same?

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

#104

Post by TheForumTroll » Tue, Feb 12, 2019, 1:16 AM UTC

21 wrote: post #34

doggydogs94 wrote: post #15

Linux is also written in C.

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

When the list says "Debian" or "Ubuntu" it includes all software in Debian and Ubuntu. That includes software like Google Chrome, Firefox, Python, Ruby, etc. For example out of the 40 listed in 2019 in Debian 36(!) are Google Chrome bugs, not Debian bugs.

Do go ahead and count CVEs in Windows and Windows software (games, office, databases, browsers, etc.) and come back with your results for an apples to apples comparison or go back to Reddit and troll.

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

#105

Post by agumonkey » Tue, Feb 12, 2019, 1:17 AM UTC

DenisM wrote: post #93

arcticbull wrote: post #91

Earlier quoted context omitted.

Luckily now we have Rust! :)

30 years of pain tho? Plus however many more years it will take to phase out existing C-based code, so another 30 at least.

the more you read about history the more you feel that 30years is nothing but required time for reactions to occur

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

#106

Post by dtrailin » Tue, Feb 12, 2019, 1:20 AM UTC

m0zg wrote: post #60

Someone1234 wrote: post #4

Just a painful reminder that they scrapped Midori[0] their managed Operating System based on Microsoft Research's Singularity project[1]. Even if it only replaced Windows LTSB/Embedded, I'd still prefer an ATM, checkout, or gas station terminal I was using was running on managed code. Doubly so for the next generation of Nuclear Powered submarines[3]. Plus between virtualisation and silo-ed software management ("Apps…

Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.b... for context). It existed so that very senior engineers wouldn't go elsewhere and cause trouble for Microsoft. It had fullfilled its purpose in that regard. I strongly suspect that some of Google's more ambitious endeavors serve the same purpose.

I don't think is is actually true since they actually did run some production services at MS like the speech service which did voice recognition for windows phones.

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

#107

Post by sanxiyn » Tue, Feb 12, 2019, 1:21 AM UTC

pcwalton wrote: post #80

rurban wrote: post #70

Earlier quoted context omitted.

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 h…

Full agreement, but I think unsafe-phobia is mostly about user-extensible nature of it. unsafe in standard library is okay, because as you said it's no more dangerous than doing it in runtime. unsafe in "your" library is not okay, because I don't trust you to modify runtime either.

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

#108

Post by icebraining » Tue, Feb 12, 2019, 1:23 AM UTC

altmind wrote: post #11

skyde wrote: post #2

we should all be using Rust then :)

or some language with the runtime. for example, c#?

Microsoft did just that, by extending C#: https://en.wikipedia.org/wiki/Singularity_(operating_system)

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

#109

Post by Dahoon » Tue, Feb 12, 2019, 1:23 AM UTC

21 wrote: post #71

CryoLogic wrote: post #59

Earlier quoted context omitted.

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.

No, because linux OS's includes a lot of software in their repositories and new packages are added all the time. Look closer at the list. "40 Debian CVEs in 2019" breaks down to this:

* Google Chrome: 36

* Artifex Ghostscript: 1

* ZeroMQ: 1

* macOS CUPS: 2

* Debian: 0

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

#110

Post by Someone1234 » Tue, Feb 12, 2019, 1:29 AM UTC

m0zg wrote: post #60

Someone1234 wrote: post #4

Just a painful reminder that they scrapped Midori[0] their managed Operating System based on Microsoft Research's Singularity project[1]. Even if it only replaced Windows LTSB/Embedded, I'd still prefer an ATM, checkout, or gas station terminal I was using was running on managed code. Doubly so for the next generation of Nuclear Powered submarines[3]. Plus between virtualisation and silo-ed software management ("Apps…

Midori, as cool as it was, was Microsoft's "no output division" (see https://archive.computerhistory.org/resources/text/DEC/dec.b... for context). It existed so that very senior engineers wouldn't go elsewhere and cause trouble for Microsoft. It had fullfilled its purpose in that regard. I strongly suspect that some of Google's more ambitious endeavors serve the same purpose.

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