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.
Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.
They can't remember how to code safely. :-)
It must have been something you assimilated. . . .
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?
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 careless use of memory creates a larger attack surface. When Chrome is capable of using all of the machine's available memory, it creates a huge attack surface for whatever today's web exploit is.
There is currently no way to limit the memory used by any browser. They will all happily consume whatever is available, and sometimes never give it back.
I've had to resort to creating a VirtualBox with 1GB of memory running Devuan just to constrain web browser memory usage. This has the added benefit of confining attacks.
You let user programs access the operating system's memory? You big dummy! What the fuck is the matter with you people? Stop it!
Microsoft never knew how to code safely, apparently. One of the many, many stories:
Microsoft Admits Normal Windows 10 Users Are 'Testing' Unstable Updates (Dec. 12, 2018)
Why they do not have that under control is puzzling. Well, not really, this is MS, after all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
... didn't he once say that Microsoft addressed the memory security issues in Windows? Maybe 15 years ago?
They have heard about it and almost completely wiped out Quality AND Control.
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.
the missing null terminator .
"I won't be back..."
-- or --
"Listen, and understand! That Terminator is not out there! It can't be bargained with. It can't be reasoned with. It doesn't feel pity, or remorse, or fear. And it absolutely will not stop... ever, until your program is dead! "
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Thank you. Someone please mod this +1 informative.
Strange then that the various rewrites of Windows and the kernel, and device drivers etc. don't use a memory-safe language. Or that I'm really pushed to name an OS that *wasn't* written in C / C++ and might be something that anyone's heard of except on a tech forum.
Maybe something to do with the fact that - despite what's claimed - memory-safe languages tend to be slower and/or consume more resources in the first place. That's the problem you need to fix - push the memory safety into hardware, so it doesn't need to be in the language. That means a complete architecture change.
Name memory-safe languages in mainstream use and you end up with:
- Python
- Java
- C# (which just makes me think ".Net Framework")
- JavaScript
- Rust and Go are in the middle ground - they can be memory safe but they often aren't.
Not sure I really want an operating system written in any of those languages. Or even written by the people who wrote those languages (Google may have written Go and use an OS of their own, but didn't exactly make Android or ChromeOS now, did they? And they are both based on what kernel, written in what language?)
Until we solve that performance problem of memory-safety, and a memory-unsafe OS underpinning the whole thing, nobody's going to bother with a memory-safe language.
Microsoft knows everything there is to know about buggy software.
Get off these 50 year old languages?
Either rewrite from scratch, or develop smart auto-migration tools then repair the results.
The auto-migration tools can try to infer "intent of a sane programmer" and put in a whole bunch of additional memory safety checks.
I suppose it could put the memory safety checks in to code in the original language (yuck) or could put them in by migrating the code to the new safer language.
BTW Betrand Meyer has some interesting stuff going on in the area of safe concurrent programs these days, using an extension of Eiffel.
Where are we going and why are we in a handbasket?
have made an Ada OS.
Domestic spying is now "Benign Information Gathering"
how can a program that runs on a host be allowed to access the host's resources? shouldn't the host be controlling what the parasite is doing? a program shouldn't be allowed to access a memory space which it is not priviledged to. The host should kill the program immediately
Microsoft doesnâ(TM)t make a C compiler. VisualC++ is just that a C++ compiler (that just happens to compile some C programs).
“Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues” .. due to the defective WinTEL x86 memory model.
How is this news?
More important, WTF has Microsoft done to prevent 70% of those errors? They've plowed an impressive amount of money creating their developer tools division. Couldn't have they shelled out a few more million to design a memory safe language and implemented it upon their VM (CLR)? Why do they perpetuate their OS product on a language (C++) utterly vulnerable and responsible for 70% of those security holes. Yes, C++ is capable of being type safe and memory secure, but apparently most people coding their product aren't capable of writing such code flawlessly in C++.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
They should teach this stuff in colleges, not in corporations. Are the selection pools for MS limited to Ivy League schools?
All warnings should still be errors
Your method forms part of a class that implements an interface including a particular parameter, but your implementation of said interface has no need for that parameter. The compiler issues a warning that your method does not use this parameter, and your policy is to treat all warnings as errors. How do you make your method fit the policy?
A race between two threads that call a language's equivalent of malloc or free can certainly corrupt their shared heap.
Well, back in the day, and I do mean the day, I was coding in Common Lisp on a Lisp Machine, which was a computer which ran no other language than lisp. So the only non-Lisp thing on the machine would have been parts of the Lisp interpreter/jit-compiler/garbage collector, process scheduler, which were written in micro-code.
So all memory access to non-trusted programmers was only allocated to the programmer as cells with safe pointers to other cells, or was numbers and safe, sized strings, and maybe a high-level typed and bounds-checked numeric array here or there etc allocated as part of the core lisp implementation. Programmers could not cast to or from pointers, nor know where the pointers, which were managed by the language environment, pointed to.
So it was basically impossible for any regular application programmer to cause any memory mis-use error.
You could still do stupid things, like infinite or memory-intensive recursion, but that would always break in a nice and controlled way.
Ah, those were the days.
Where are we going and why are we in a handbasket?