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

121–130 of 180 posts

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

#121

Post by rurban »

phkahler wrote: post #102
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.

>> Nonsense. Rust safeties are massively overhyped. No. They are not. You obviously have not done your homework on the subject.

Obviously not. I've only worked on two different compilers/languages which do provide all three safeties, while you probably wouldn't even be able to name a single one. It's embarrassing.

It's a nice language, and safer than C/C++ but for sure not a safe one, even if thousands of newbies will repeat it constantly.

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

#122

Post by spricket »

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

Java is trying to catch up, with active research projects for copying C#'s native types, a "Java on Java JIT" (Graal). And most interesting to me, fiber based green threads.

If these projects bear fruit, we may be only a few years away from Java exceeding native code speed in most applications

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

#123

Post by james_s_tayler »

AgentME wrote: post #117
james_s_tayler wrote: post #49

Earlier quoted context omitted.

Computer security is a fundamentally asymmetric game. Your entire stack needs to contain zero mistakes and an attacker only needs to find one. Also the resources you would expend trying to find and patch every last hole would break the economics. It is what it is.

>Also the resources you would expend trying to find and patch every last hole would break the economics. If people built with things that weren't made of holes (ie. using memory safe languages), then there wouldn't need to be much effort in the "find and patch" side of things.

Are you absolutely certain of that conclusion?

I'll agree with the sentiment that memory safe languages are less prone to security holes because by nature they entirely remove a whole class of issues related to managing memory...

but I can't help but think that it still stands to be the case that finding and patching the remaining holes that aren't related to memory management would still break the economics.

Perhaps the one thing I could imagine that might make a difference is regulations coming into force that mandated pentests / fuzzing for companies producing software doing a certain amount in revenue. It's been my experience that that stuff gets done but it's once in a blue moon. And stuff is always turned up. I'm yet to work anywhere where it is part of a regular process.

Even if it were I'm always blown away by security researchers who spend months and months attacking something and finally crack it then give a presentation about how they did it. There can't even be that many people on Earth with the level of skillset required.

I dunno... the economics of it seem to play out like "let's just deal with the fallout of an incident when it happens because that's cheaper than investing in security"

The asymmetric nature of finding holes vs not creating them combined with the asymmetric nature of the business value of investing in security is just a mildly awful combination.

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

#124

Post by ilovecaching »

duneroadrunner wrote: post #113
sumitgt wrote: post #77

Earlier quoted context omitted.

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

Replacing existing unsafe C++ elements with compatible memory safe substitutes[1] might be more expedient. The conversion can even be automated[2] for parts of the code that aren't performance critical. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

I'm not a fan of these types of efforts. You could be putting energy into making Rust better. Memory management aside, C++ has become an incomprehensible mess filled with cruft. Rust does much more than provide safety, it provides better abstractions, a better type system, and actual tooling. Building tools for C++ to keep the ship afloat just means we have to deal with writing C++ longer.

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

#125

Post by maxxxxx »

naikrovek wrote: post #119
maxxxxx wrote: post #94

Earlier quoted context omitted.

I have never heard about IoT Core before, only IoT enterprise and LTSC. This would actually have been an interesting choice for the project I am working on right now. It's really infuriating how many versions MS is cranking out without clear differentiation between them and even when you talk to MS reps they know nothing about the options.

IoT core is not new, not a secret, and Microsoft makes no effort to hide it. Your MS reps need to be fired if they do not know about IoT Core, or chose not to tell you. Also, I personally find it best to never rely on a rep from any company to give me the truth about their product line. I will make time to do preliminary research (at least) myself. Microsoft will ALWAYS push IoT Enterprise over IoT Core because IoT C…

Our reps wanted to push us into enterprise. We went with LTSC against their advice because the upgrade cycle is much better.

IoT Core looks interesting but I am not sure if we are ready for App Store only. Does it even support WPF or only UWP?

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

#126

Post by asdff »

jodrellblank wrote: post #103
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?

Shutting down servers or stealing credit card info certainly has a cost

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

#127

Post by zoeysaurusrex »

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.

Based on knowing and being firsthand friends with several Midori devs, I’m going to assert that this is simply not true. The majority of them were just reassigned when the project was cancelled.

Many of the innovations from Midori were included in other projects. The project may have “failed” but it was far from a failure.

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

#128

Post by naikrovek »

maxxxxx wrote: post #125
naikrovek wrote: post #119

Earlier quoted context omitted.

IoT core is not new, not a secret, and Microsoft makes no effort to hide it. Your MS reps need to be fired if they do not know about IoT Core, or chose not to tell you. Also, I personally find it best to never rely on a rep from any company to give me the truth about their product line. I will make time to do preliminary research (at least) myself. Microsoft will ALWAYS push IoT Enterprise over IoT Core because IoT C…

Our reps wanted to push us into enterprise. We went with LTSC against their advice because the upgrade cycle is much better. IoT Core looks interesting but I am not sure if we are ready for App Store only. Does it even support WPF or only UWP?

There is NO graphical Win32 stuff; UWP only. There are some non-graphical Win32 APIs but not like full Windows.

It's basically .net core and UWP and all the old familiar Windows stuff is gone.

IoT Core is either the best possible Windows or the worst possible Windows, depending on your point of view.

For some things, it's a perfect fit. If you can't fit into a .net core & UWP ecosystem entirely then it won't be a good fit if you need a GUI.

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

#129

Post by maxxxxx »

naikrovek wrote: post #128
maxxxxx wrote: post #125

Earlier quoted context omitted.

Our reps wanted to push us into enterprise. We went with LTSC against their advice because the upgrade cycle is much better. IoT Core looks interesting but I am not sure if we are ready for App Store only. Does it even support WPF or only UWP?

There is NO graphical Win32 stuff; UWP only. There are some non-graphical Win32 APIs but not like full Windows. It's basically .net core and UWP and all the old familiar Windows stuff is gone. IoT Core is either the best possible Windows or the worst possible Windows, depending on your point of view. For some things, it's a perfect fit. If you can't fit into a .net core & UWP ecosystem entirely then it won't be a goo…

UWP is a no-go already. No way we can port our WPF code.

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

#130

Post by max76 »

jodrellblank wrote: post #103
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?

The bandwidth costs for Globalsign incurred for revoking SSL certificates in response to Heartbleed was estimated to $400K in a Cloudflare blob post [0] and eWeek estimated the total cost of Heartbleed to be $500M [1], although admittedly this price tag is an educated guess.

You're question is expensive to whom. The answer is the expenses are spread across the entire industry. Every time a software author needs to write a patch the bigger cumulative expense is to all of their customers that need to apply the patch.

[0] https://blog.cloudflare.com/the-hard-costs-of-heartbleed/ [1] https://www.eweek.com/security/heartbleed-ssl-flaw-s-true-co...

Post reply on HN