Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues (zdnet.com)

Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. From a report: Memory safety is a term used by software and security engineers to describe applications that access the operating system's memory in a way that doesn't cause errors. Memory safety bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses. Users who often read vulnerability reports come across terms over and over again. 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. Speaking at the BlueHat security conference in Israel last week, Microsoft security engineer Matt Miller said that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs.

Comments

Meaning

[fahrbot-bot]

Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

They can't remember how to code safely. :-)

Re:Meaning

[willaien]

True. Part of the issue is that some languages easily lets you develop programs that don't use memory safely. C/C++ easily let you develop applications that violate memory safety.

You have to be constantly vigilant, and everyone else who develops for the same project has to be constantly vigilant. Mistakes will happen, and nothing will call you out on it unless you do extensive memory safety testing or configure and use some tools that help detect common memory safety issues and hope that you catch anything they don't.

Re:Meaning

[willaien]

Large systems require a lot of developers, and even the best developer can have a bad day and make a mistake that potentially exposes their application to various memory exploits. Sometimes you have to pay the tax of having better developers, more tools, etc. to make the applications safer.

But, in general, as processors get faster, memory amounts in modern computers gets higher, we should move away from such languages except for projects that require them.

Re:Meaning

[epine]

C/C++ easily let you develop applications that violate memory safety.

The modern C++ idiom easily lets you develop applications where you barely touch memory safety yourself, and competent libraries (such as the STL) do all the hard lifting.

C does not let you do this in any natural way.

If you wish to write your own RAII-compliant classes, you do need to book off half a day to watch (and digest) this series of three videos: CppCon 2014: Jon Kalb "Exception-Safe Code, Part I"

Outrageous investment? Well, it's your life.

Re:Meaning

[willaien]

Fair point. If you are careful to not use any of the low level memory allocation functions except in exceptional circumstances, you can easily create modern C++ applications without memory safety issues by sidestepping them entirely.

However, a lot of applications have been developed before these paradigms became common, and I'm sure that a lot of applications have been developed since by developers who didn't know any better or reject them for whatever reason and thus don't use those paradigms.

I guess my critique against C++ is against the older style of C++, the parts that are there for compatibility with C code. And against any codebases that use those.

Re:Meaning

[gweihir]

The ideology here is with the Rust fanatics that completely ignore that developer quality is critical, regardless of language. While C does allow you to do a lot of dangerous things, a modern compiler will warn you and a competent developer will know how to avoid most of them. The memory problems in C are a symptom, not a root cause and that is what you people consistently get wrong.

Re:Meaning

[e432776]

I've had it! I'm taking all the memory out of my machine to increase its security. Hold on, brb!

Re:Meaning

[lgw]

I did low-level code for ~15 years without ever having a memory leak or memory safety bug. Not because I'm especially diligent, but because I was in areas where it just didn't come up. From primitive assembly (with no dynamic memory allocation in the first place, it's hard to screw it up) to C++ done right.

Those odd corner cases are nearly the same set of places where it still makes sense to use low-level languages in the fist place. These days, if you're creating a large C code base where you're constantly allocating and freeing resources, it's almost certainly the wrong tool for the job. OTOH, if half your variables are "const volatile" because they're really memory-mapped sensors, or you only allocate memory at startup because you can't do anything dynamic in your hard realtime system, then it's both the right tool and these memory-use bugs are barely relevant.

Re:Meaning

[theweatherelectric]

It is a poor craftsman that blames his tools

A good craftsman doesn't use poor tools. Harden up and get some practicality, my son.

Re:Meaning

[Joce640k]

To say this is the fault of C and C++ is disingenuous.

Read the slides from the talk. They specifically mention C++ as a problem to be solved. And they're right.

C++ allows you to write safe code, much safer than C.

The probelem is C programmers calling themselves C++ programmers when all they're really doing is using a C++ compiler to write C.

Re:Meaning

[serviscope_minor]

The ideology here is with the Rust fanatics

How about we have a sensible adult conversatio where we ignore the fanatics of any sort? Does Rust have fanatics who say stupid stuff? Yep. Does C? Oh hell yes. So does C++, python, Ruby, PHP and probably there's even a MUMPS fanatic out there if you look hard enough.

I'm a C++ developer day to day but familiar with lots of languages. I have read about Rust but neverused it in practice and aren't likely to start any time soon for various reasons. However...

While C does allow you to do a lot of dangerous things, a modern compiler will warn

Yes, a bit. Compiler warnings are getting better year on year. But they still miss a LOT of stuff. That's why we have static analyzers, valgrind and sanitizers.

The difference with Rust is it's baked into the type system so it's precise. Outside of a compiler bug (and unsafe block) you will NEVER get a use after free.
The thing is in C++ you escape those by being careful about ownership. It's still possible to slip up though.

competent developer will know how to avoid most of them.

Most, but not all. And not all of the time.

Re:Meaning

[squiggleslash]

I think a good reason to suggest C is one of the worst languages is to compare it with PHP. PHP is a terrible language with obvious flaws. C is also a terrible language with obvious flaws.

But... my experience is that the average PHP programmer does actually recognize that the language they're being forced to program in is shit. They know mistakes are going to occur no matter how smart they are and that a sizable number of those will be because the language is hot garbage.

C, on the other hand, seems to attract a bizarre level of machismo, people absolutely insisting that C is the best, and the only reason why there's so much terrible C written is that the average programmer is worse than they are, because C, you know, it needs to be written by a true expert. A REAL C programmer. Programming in REAL C. Alongside REAL men, REAL women, and REAL small furry creatures from Alpha Centauri.

The only other language I can think of that attracts that level of misplaced arrogance is C++, which is kinda what you'd expect given one is an extension of the other.

A missing null is a terrible thing.

[willaien]

I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?

Re:A missing null is a terrible thing.

[gweihir]

I am sure they were aware. They likely just badly misjudged the typical quality of coders.

Re:A missing null is a terrible thing.

[Freischutz]

I am sure they were aware. They likely just badly misjudged the typical quality of coders.

More likely they just didn't anticipate the degree of maliciousness we have today and they probably also didn't expect C to have such a long lifespan.

Re:A missing null is a terrible thing.

[willaien]

To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.

I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.

Re:A missing null is a terrible thing.

[Krishnoid]

Joel Spolsky has provided some background on this.

Re:A missing null is a terrible thing.

[goose-incarnated]

I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?

How does pointer+length fix a maliciously (mal)formed string?

For each string that enters the system you'll need to check the length against the data you've been given, at which point you may as well have just used a terminating NULL because the result is the same (because the length might be lying to you)

Okay, lets say that you *are* checking the length against the input - what do you do when the length is (uint64_t)-1? At that point you may as well have just used a terminating NULL anyway, because the result is the same.

Okay, so let's say that you enforce a maximum string length as strings enter the system - you can do the same with a null-terminated string too.

Any safety that a ptr+length solution gives you, you can already get from a null-terminated string currently, right now.

In fact, the null-terminated string is actually safer than ptr+length because there is only ever one source of the string's length, and that is the string itself. With a ptr+length solution there are many more opportunities for a string to have a length indicator that is different to it's actual length.

The problem isn't the existence of a null-terminated string; it's the overflows that occur because code is relying on a length that is lying about the *actual* string length (as in heartbleed), instead of (correctly) enforcing a terminator on the input (once the end of the input is reached).

The other problem is that, right now, you can validate data entering the system to enforce limits, and test the program against these limits using valgrind, but too few systems are tested this way; if they were then we wouldn't be seeing buffer overruns at all, strings or otherwise.

How many Windows C (or C++) devs actually use a Windows equivalent of valgrind? I don't know of any.

So create standards-compliant functions MickeySoft

[Anonymous Coward]

The C Standard added Annex K, Bounds-checking Interfaces in an effort to address this.

Every see all those "sprintf() is deprecated" misleading error messages from Visual Studio? The ones that make you think that functions that are required by the C standard are "deprecated"?

Well, Microsoft on the surface seems to be pushing you to use those "safer" Annex K functions? No, not really. They're pushing you to use Microsoft's bullshit versions. Per the C committee:

Field Experience With Annex K — Bounds Checking Interfaces

...

Microsoft Visual Studio

Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1. For example, it doesn't provide the set_constraint_handler_s function but instead defines a _invalid_parameter_handler _set_invalid_parameter_handler(_invalid_parameter_handler) function with similar behavior but a slightly different and incompatible signature. It also doesn't define the abort_handler_s and ignore_handler_s functions, the memset_s function (which isn't part of the TR), or the RSIZE_MAX macro.The Microsoft implementation also doesn't treat overlapping source and destination sequences as runtime-constraint violations and instead has undefined behavior in such cases.

As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable.

So, MickeySoft, just STFU about memory problems when you use them as nothing more than an excuse to push your proprietary version of C on the population.

Doesn't help if you remember

[SuperKendall]

They can't remember how to code safely. :-)

The problem is, even if you know full well how to "code safely" all it takes is one slip, or some interaction with another part of the system you didn't fully understand, and you are done.

That is why for most things, sadly languages that allow such slip-ups simply have to go. We cannot live like this forever in a world of chaos where any system of any size is just moments away from disaster or infiltration. As an industry we have to somehow ratchet ourselves forward, even if only a little bit.

Re: Doesn't help if you remember

[Monster_user]

Uhm, first one with 900+ vulnerabilities is Debian. What they don't indicate is what branch or branches of Debian is included. Debian is not a single release, but a system. There is the "stable" branch, which is supposed to be secure, and is akin to Windows 10 LTSB (or Windows 7). There is the unstable branch which is more current and akin to the Windows 10 Deferred channel. Then there is the Testing branch which is akin to Windows 10 Insider Preview, and isn't expected to be secure.

The question is whether these 900+ vulnerabilities are 300 duplicated vulnerabilities for each branch, or whether they are more heavily biased towards the testing or stable branches.

Once you get past Debian and Android, the next ones are at around the 300 mark, and Windows 10 is in the top ten.

And if you really want to compare Linux, not that RedHat Enterprise Linux is much further down the list than even Windows Server, much less Windows 10.

Re:Doesn't help if you remember

[squiggleslash]

The solution is not to ban languages the youngin's don't like, the solution is for MS to stop releasing crap

If you've reached an age where you feel you can describe Rust users as "youngins" and you don't see the value in Rust and the problems with C, then there's a serious problem.

(Besides, nobody's taking your C compiler away from you or talking about that - they're talking about not using it any more for code you need to be able to trust. There is absolutely no reason on Earth for a replacement TCP/IP stack, web browser, or email client you switch to be written in C. There are safer alternatives that are just as efficient. If you want to write them in C, go ahead, just expect thinking people to want alternatives to your implementation written in safer environments.)

C's flaws are obvious. Why do people feel the need to pretend it's OK? You don't Slashdot flooded with apologists for PHP every time a Wordpress vulnerability gets publicized.

Re:Doesn't help if you remember

[theweatherelectric]

I do not know how many vulnerabilities would exist if we included everything that uses the MS ecosystem as this does with Debian

So you're saying Debian's development, packaging, and distribution model is fundamentally flawed from a security point of view? That doesn't inspire me to use Debian.

There were 775 Windows 10 vulnerabilities in 2018

There were 255 Windows 10 vulnerabilities in 2018. I don't know where you're getting 775 from. You're probably confusing it with the "all time leaders" vulnerability counts. If we look at the all time leaders, Debian is number 1 and "Linux Kernel" is number 2.

MS's Jim Allchin...

[QuietLagoon]

... didn't he once say that Microsoft addressed the memory security issues in Windows? Maybe 15 years ago?

Re:MS's Jim Allchin...

[drinkypoo]

... didn't he once say that Microsoft addressed the memory security issues in Windows? Maybe 15 years ago?

Microsoft developed and provided all the tools you'd need to avoid the problem, and then apparently never bothered to use them themselves.

This is not new

[MobyDisk]

This has been the vast majority of security bugs for 30 years. This is why every new language in the last 20 has sort of automatic memory management. Even C++ has moved in this direction with the vast selection of smart pointers.

Re:Memory Footprint

[sexconker]

32GB in my laptop. Chrome is using 600MB and ive done nothing special. It hardly consumes all available ram.

Yeah, but once you OPEN Chrome it'll use 6 GB.

Re:This is about MS bugs, not general ones

[gweihir]

You seem to be unaware of the scales here: A typical Linux distro will have > 1000 applications. MS does not even make that many. And no, it is not all memory safety. This is an MS issue.

Should

[AHuxley]

have made an Ada OS.