
Microsoft: 70 percent of all security bugs are memory safety issues - clouddrover
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
======
Someone1234
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") it seems
entirely plausible to move the PC/Laptop to the next generation.

[0]
[https://en.wikipedia.org/wiki/Midori_(operating_system)](https://en.wikipedia.org/wiki/Midori_\(operating_system\))

[1]
[https://en.wikipedia.org/wiki/Singularity_(operating_system)](https://en.wikipedia.org/wiki/Singularity_\(operating_system\))

[3] [https://mspoweruser.com/uks-nuclear-submarines-runs-
windows-...](https://mspoweruser.com/uks-nuclear-submarines-runs-windows-xp-
submarines/)

~~~
m0zg
Midori, as cool as it was, was Microsoft's "no output division" (see
[https://archive.computerhistory.org/resources/text/DEC/dec.b...](https://archive.computerhistory.org/resources/text/DEC/dec.bell.no_output_division_C-
I_TF;productivity_review.1982.102630376.pdf) 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.

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

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

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

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

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

------
DenisM
It's a pity Modula-2 did not gain wider adoption 30 years ago - it has almost
all the memory safety of managed languages and none of the performance
penalties. Array bounds were checked by compiler and the only available unsafe
operation was deallocate, all other unsafe operations were sequestered into
separate module which could be easily isolated, audited, and/or banned as
appropriate. Life could have been so much better.

~~~
arcticbull
Luckily now we have Rust! :)

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

~~~
lewisinc
It depends how it gets prioritized by the companies that own and contribute to
these codebases - both open and private source. Right now there's not much
incentive financially to migrate away from any of the existing code, so more
often than not it will not happen.

One reason why we're seeing stuff like the
[FirecrackerVM]([https://firecracker-microvm.github.io](https://firecracker-
microvm.github.io)) or
[AzureIoTEdge]([https://github.com/Azure/iotedge](https://github.com/Azure/iotedge))
is that the companies behind them know they will attract privacy-/security-
minded customers they might not otherwise have.

There's other reasons as well, but this is just what stands out to me first.

------
max76
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. Critical security
flaws involving unauthorized access to data will continue to appear until we
make the transition. The cost of these security flaws is likely to become more
expensive than the cost of replacing the existing software. To make matters
worse we are continuing to write more unmanaged code everyday.

~~~
jodrellblank
_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?

~~~
max76
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/](https://blog.cloudflare.com/the-hard-costs-of-heartbleed/) [1]
[https://www.eweek.com/security/heartbleed-ssl-flaw-s-true-
co...](https://www.eweek.com/security/heartbleed-ssl-flaw-s-true-cost-will-
take-time-to-tally)

------
ilovecaching
Rust couldn't solve all of these bugs, but it certainly would have drastically
reduced the total amount. The code would also be drastically easier to write
and debug. C++17 is still a total mess to write, despite what Microsoft might
tell you in their docs. Really doesn't make sense to me, outside of the sunk
cost fallacy, why Microsoft isn't pivoting to Rust if they want to write C++.

~~~
coldcat
you could ask the same question for every os. And none choose Rust even the
recent like fushia. BTW go ask Linus to switch to Rust I'm waiting for you
there.

~~~
ilovecaching
Fuchsia is using Rust for some pieces. That's what I assume MS would do. MS is
a company with tons of products, not just an OS, and certainly not a single
monolith. You wouldn't rewrite everything in a day, you would slowly move
things over time.

------
sempron64
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 series of mitigations? As soon
as we add layers of security (Stack cookies, ASLR, memory "safe" languages
with exploitable runtimes, etc.) it seems like new methods are invented to
bypass them and those methods gradually become widespread (ROP chains, runtime
fuzzing, rowhammer, speculative execution exploits). What is the next "70
percent" of security bugs? Is there an end to this race?

I think the only thing in the future that can ever be as secure as in-person
conversation and paper records is devices using zero-intermediary
communication, in the style of an ansible
[https://en.wikipedia.org/wiki/Ansible](https://en.wikipedia.org/wiki/Ansible),
and extremely restricted storage which can only store data and not arbitrary
application state.

~~~
monocasa
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 LOC of your compiler even though you need that for your program
ultimately.

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

~~~
sanxiyn
> Moreover, verification is done with respect to specific properties that
> ensure no attacks of a particular kind.

No. seL4 proved functional correctness. It eliminates all attacks, not just
particular kinds.

Functional correctness means implementation matches specification. As a
corollary, seL4 has no buffer overflows. Proof: Assume seL4 has a buffer
overflow. Exploit it to run arbitrary code. Arbitrary code execution is not
part of specification, hence implementation does not match specification,
leading to contradiction. QED.

Above proof applies to use after free, or any other exploits enabling
arbitrary code execution, including methods which are not discovered yet.

~~~
burntsushi
I read this and thought, "this can't be right, they must be assuming some
things."

According to them, they, sensibly, are indeed assuming some things to be
correct without proof:
[http://sel4.systems/Info/FAQ/proof.pml](http://sel4.systems/Info/FAQ/proof.pml)

This is effectively the same idea behind Rust's `unsafe`. It represents the
things you assume to be true. Of course, when compared to seL4, the scales are
massively different. :-)

------
kccqzy
> Terms like buffer overflow, race condition, page fault, null pointer, stack
> exhaustion, heap exhaustion/corruption, use after free, or double free --all
> describe memory safety vulnerabilities.

Page faults are fine. Null pointers are fine; just don't dereference them.
Race condition is a much more general term that can cover non-memory races
too; perhaps they meant data races.

~~~
ComputerGuru
Yes, I don’t think race conditions should feature in a list of memory safety
issues. However page faults can be _not_ fine - on some hardware it can be a
hard fault.

------
dtrailin
Link to the presentation this article is based one but doesn't site for some
reason: [https://github.com/Microsoft/MSRC-Security-
Research/raw/mast...](https://github.com/Microsoft/MSRC-Security-
Research/raw/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf)

------
fouc
First 38% of bugs at Airbnb could have been prevented by using type safety.
Now 70% of all security bugs at Microsoft could have been prevented by using
memory safety.

~~~
spricket
Exactly, this explains why my Java code is 108% bug free

------
HugoDaniel
In 2015 they become the first gold contributor to OpenBSD

[https://www.zdnet.com/article/microsoft-becomes-openbsds-
fir...](https://www.zdnet.com/article/microsoft-becomes-openbsds-first-gold-
contributor/)

------
skyde
we should all be using Rust then :)

~~~
reallydude
> Microsoft: 70 percent of OUR security bugs are memory safety issues

Fixed the title. This is not an analysis about general software errors.

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

------
Animats
This late? With Microsoft's move to C# and the Static Driver Verifier? The
latter pretty much fixed this for drivers, which used to be the biggest source
of kernel crashes. I thought Microsoft was past this.

~~~
pjmlp
There is still a strong C and C++ community at Microsoft.

They are the only OS vendor (on consumer space) still having a full stack
support for C++, with internal pushes to keep it going.

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

------
myth17
Where can I find the original presentation from Microsoft's engineer?

~~~
est31
[https://twitter.com/epakskape/status/1093488162318491648](https://twitter.com/epakskape/status/1093488162318491648)

[https://github.com/Microsoft/MSRC-Security-
Research/blob/mas...](https://github.com/Microsoft/MSRC-Security-
Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf)

------
davidjnelson
Fuzz testing is a useful tool for finding these types of bugs. See
[https://en.m.wikipedia.org/wiki/Fuzzing](https://en.m.wikipedia.org/wiki/Fuzzing)

------
donatj
29% SQL Injection?

------
doggydogs94
Linux is also written in C.

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

~~~
CryoLogic
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).

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

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

~~~
Dahoon
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/](https://lwn.net/Articles/410606/)

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

~~~
pjmlp
Google thinks otherwise, hence Linux Kernel Self Preservation Project.

~~~
Dahoon
Kernel Self Protection Project (:

[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)

~~~
pjmlp
I always get it wrong. :)

