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.
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.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.