Live data from Hacker News

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

zdnet.com

131–140 of 180 posts

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

#131

Earlier quoted context omitted.

Well, that wouldn't eliminate everything (row-hammer, speculative execution), but it would probably get rid of the most common culprits - buffer overflows and use after free.

Things like row hammer will not get attention until they are commonly used. Rust does eliminate the most common vulnerabilities and should be seriously considered for any new project that would otherwise be written in C.

Oh, I completely agree. It's just easy to overstate Rust's guarantees, which doesn't do anybody any good.

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

#132
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…

Agreed on principle but not sure it can be bootstrapped.

What would you write, say, v8 in? Rust doesn't have any provisions against type confusion, JIT bugs, etc, and v8 seems way too complex for a formal verification.

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

#134
post #60

Earlier quoted context omitted.

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.

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.

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

#135
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…

Agreed on principle but not sure it can be bootstrapped. What would you write, say, v8 in? Rust doesn't have any provisions against type confusion, JIT bugs, etc, and v8 seems way too complex for a formal verification.

Does C/C++ have any provisions against type punning or JIT bugs? The fact that you have to use unsafe code for a lot of things in a JIT doesn't change the basic reality that Rust is safe by default, whereas C/C++ cannot be made memory-safe practically, except for small programs like seL4.

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

#136
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 is incredibly stingy about anything unsafe. Even unsafe blocks of code are borrow-checked.

Considering how slowly things run these days on any OS, and OS's specifically having performance issues, I doubt the user experience will benefit from a completely managed OS either, but I'm no expert.

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

#137

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 was a victim of the WinDev vs DevDiv political wars.

The most recent example is Kenny Kerr complaining that although they made a big effort to migrate from C++/CX into C++/WinRT, the large majority prefers to code in .NET nowadays.

https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/

However many of the Midori outcomes have landed in .NET, namely .NET Native, async/await, TPL, span, blittable structs, immutable data on Rosyln, so not everything was completly lost. As side note WP8 Bartok AOT compiler also comes up in Singularity.

So fortunely not everything gets lost.

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

#138

I hope Rust comes of age in a few years. Java, Go, and C# are above 50% "native" speed in every benchmark I've run across, but the mantra continues to be "why would I pick something slower?". Rust is the answer everyone wants, even if they don't really need it. An aside, C# in .NET core is getting very close to native speed. It's passed Java in many benchmarks, mostly due to type reification and lack of boxed primiti…

Unity's work on HPC# (High Performance C#) seems like a good possibility of a middle ground: Use C# where performance is not critical but you want safety, use HPC# when you absolutely need restrictions on performance.

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

#139
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. I think that you massively under-estimate the cost of rewriting all that code. Yes, the security flaws are expensive. Rewriting the code would be, I'd guess, at least one order of magnitude more expensive.

If we start getting more recalls and lawsuits due to CVEs, things will change.

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

#140

I hope Rust comes of age in a few years. Java, Go, and C# are above 50% "native" speed in every benchmark I've run across, but the mantra continues to be "why would I pick something slower?". Rust is the answer everyone wants, even if they don't really need it. An aside, C# in .NET core is getting very close to native speed. It's passed Java in many benchmarks, mostly due to type reification and lack of boxed primiti…

I hardly use C++ since 2006, only when I am forced to step outside Java/.NET or happen to actually do some hobby projects in C++.

Meanwhile at work, a couple of C++ servers have been replaced by managed ones across a couple of projects.

Even with the current stacks, not every business needs the ultimate performance across all stack, as an example Siemens and Zeiss use .NET on their digital imagining solutions, with native code only in the hotspots.

Post reply on HN