Slashdot Mirror
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.
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.
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.
Joel Spolsky has provided some background on this.
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.
Socialism: a lie told by totalitarians and believed by fools.