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]

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

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

Re:A missing null is a terrible thing.

[Krishnoid]

Joel Spolsky has provided some background on this.

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.