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

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

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.

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:A missing null is a terrible thing.

[Krishnoid]

Joel Spolsky has provided some background on this.

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.

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.