Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Microsoft Security IT

Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues (zdnet.com) 193

Posted by msmash from the closer-look dept.
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.
This discussion has been archived. No new comments can be posted.

Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues More

Microsoft: 70 Percent of All Security Bugs Are Memory Safety Issues

Comments Filter:

  • Meaning (Score:5, Funny)

    by fahrbot-bot ( 874524 ) on Monday February 11, 2019 @03:25PM (#58105818)

    Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

    They can't remember how to code safely. :-)

    • Re:Meaning (Score:4, Interesting)

      by willaien ( 2494962 ) on Monday February 11, 2019 @03:31PM (#58105860)

      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: (Score:2, Insightful)

        by kalpol ( 714519 )
        C/C++ gives you CONTROL. If you don't have enough knowledge to use it properly, use something else. It's as if you can't drive a car, you are probably going to hit a tree. But if you can drive, you have whole areas open up to you for exploration and increases in productivity.

        • Ooh, analogies!

          Did you know that modern cars have more safety features, meaning that you're much less likely to die in a collision in a modern vehicle, due to things such as airbags, seat belts, crumple zones, automated braking, etc.?

          Just like modern, higher level languages give developers enough access to much of the system without requiring you to worry as much about memory safety, most car drivers don't need drag racers to get to work.

      • Re:Meaning (Score:4, Informative)

        by epine ( 68316 ) on Monday February 11, 2019 @04:36PM (#58106336)

        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" [youtube.com]

        Outrageous investment? Well, it's your life.

        • Fair point. If you are careful to not use any of the low level memory allocation functions except in exceptional circumstances, you can easily create modern C++ applications without memory safety issues by sidestepping them entirely.

          However, a lot of applications have been developed before these paradigms became common, and I'm sure that a lot of applications have been developed since by developers who didn't know any better or reject them for whatever reason and thus don't use those paradigms.

          I guess my cr

          • Re:Meaning (Score:5, Interesting)

            by lgw ( 121541 ) on Monday February 11, 2019 @06:52PM (#58107028) Journal

            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.

    • Microsoft never knew how to code safely, apparently. One of the many, many stories:

      Microsoft Admits Normal Windows 10 Users Are 'Testing' Unstable Updates [forbes.com] (Dec. 12, 2018)

    • Doesn't help if you remember (Score:4, Insightful)

      by SuperKendall ( 25149 ) on Monday February 11, 2019 @03:39PM (#58105920)

      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.

    • I've had it! I'm taking all the memory out of my machine to increase its security. Hold on, brb!

    • Re: (Score:2)

      by dgatwood ( 11270 )

      Around 70 percent of all the vulnerabilities in Microsoft products ... are memory safety issues.

      They can't remember how to code safely. :-)

      Not at all. They have a huge legacy codebase. Rewriting all those strcpy and strncpy calls to strlcpy takes time.

      And except for modern C++, C and C++ historically lacked reference counting, which gives you the additional joy of debugging use-after-free violations. These bugs are remarkably easy to cause and remarkably hard to detect until something just randomly crashes.

  • A missing null is a terrible thing. (Score:3)

    by willaien ( 2494962 ) on Monday February 11, 2019 @03:26PM (#58105826)

    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?

    • Re: (Score:3)

      by gweihir ( 88907 )

      I am sure they were aware. They likely just badly misjudged the typical quality of coders.

      • I am sure they were aware. They likely just badly misjudged the typical quality of coders.

        More likely they just didn't anticipate the degree of maliciousness we have today and they probably also didn't expect C to have such a long lifespan.

        • To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.

          I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.

          • To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.

            I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.

            True, but C has also suffered from stagnant development and downright neglect. C could have benefitted immensely from some project like the C++ boost project whose features get integrated into progressive C updates a long time ago.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      They might have, but doing so wouldn't have avoided the problem -- even with a ptr+length scheme, you're still dealing with pointer artihmentic, and so it's still quite easy to mess up and read/write outside of your buffer's bounds, if you aren't careful.

      An effective fix requires language support, with the holy grail being a language where a buggy or insecure program simply won't compile, and therefore any program that does compile is much more likely to be secure/bug-free. Languages like C# and Rust are h

      • It would have brought a different set of problems, for sure. And we can never know what hundreds of thousands of developers, etc. would have discovered about it. But, it certainly would have made certain classes of issues pretty much non-existent.

      • Languages like C# and Rust are headed in that direction, although I think there is still a long way to go before we have a language that is both "safe" and efficient.

        You say that like Rust isn't "safe" and efficient.

        • Perhaps the requirement not yet achieved would be:
          safe and efficient, and simple and comprehensible.

          The former two for obvious reasons, and the latter two so that it is adopted widely for development, and so that it is maintainable.

      • Re: (Score:2)

        by dgatwood ( 11270 )

        They might have, but doing so wouldn't have avoided the problem -- even with a ptr+length scheme, you're still dealing with pointer artihmentic, and so it's still quite easy to mess up and read/write outside of your buffer's bounds, if you aren't careful.

        Yeah, but other languages that existed at the time (Pascal) had run-time bounds checking, and there's no reason C couldn't have done that too, with the addition of a slightly richer string syntax. Though they couldn't have anticipated the long-term securit

    • I do remember one of the creators of C describing that particular decision - and it was a decision - to be their greatest mistake. I loathe that language, along with those which share these deficiencies.

      • Re: (Score:2)

        by dfghjk ( 711126 )

        Spoken like a true moron. I suppose lack of memory safety is a "decision" for processor manufacturers too. How dare assemblers not implement proper heap protection!

        If you can't understand tools and how they are used, find something else. Your inability to code properly is not C's fault.

        • ...I suppose lack of memory safety is a "decision" for processor manufacturers too. How dare assemblers not implement proper heap protection!

          .

          Actually, it was a decision [wikipedia.org], and some vendors made different choices. Quite successful choices.

          while (*p++=*q++);
          when you actually mean
          p = q;
          (and the idiom depends on idiosyncrasies of the PDP-11 instruction set), was a stupid decision.

    • Re: (Score:2)

      by hAckz0r ( 989977 )

      I was just learning how wonderful the VAX Descriptor could be right when this char *c=null thing took hold in WinNT. No easy way to double check your string lengths or anything. WinNT 3.1 even pushed GDI into the kernel, and they got what they expected. Memory performance right when the memory price point was becoming really cheap, and lots and lots of memory bugs.

      Somehow in my sleep, I could hear Dave Cutler screaming "Noooooooooo"!!!!!!!.

    • Re:A missing null is a terrible thing. (Score:5, Interesting)

      by Krishnoid ( 984597 ) on Monday February 11, 2019 @04:44PM (#58106370) Journal

      Joel Spolsky has provided some background [joelonsoftware.com] on this.

    • 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?

      How does pointer+length fix a maliciously (mal)formed string?

      For each string that enters the system you'll need to check the length against the data you've been given, at which point you may as well have just used a terminating NULL because the result is the same (because the length might be lying to you)

      Okay, lets say that you *are* checking the length against the input - what do you do when the length is (uint64_t)-1? At that point you may as well have just used a terminating NULL anyway, because the re

      • Not going to do a point by point breakdown of that, but, I dread to think of how expensive it would be to get the length of a string if you're considering uint64 sized strings if it were null-terminated.

      • I feel like there's a fundamental misunderstanding of what ptr+len means.

        It means that all of the c api's functions would be based around this idea. So, for example, "get_s()" would return a structure containing the length of the string and a pointer to the first character. It means that "str_concat()" would take in two of these structures and return a new one, etc. (or, some idiomatic c equivalent of these things).

        Exactly how do you think that a "malformed string" would get in that lies about its length? I

        • And, yes, I realize that you can certainly write code that creates malformed strings. The point is that the standard C library itself would have memory safety built into its own handling of strings.

    • Heartbleed came about because the incoming string was ptr+length.

      There is no security advantage at all in ptr+length. What there is, is a speed advantage. In Delphi it's known as "shortstring", and is an excellent tool for high speed string manipulation where no string will be longer than 255 bytes.

    • C was designed to be more of a shorthand for assembly rather than a high level language.

      There is no string type in C. The C Standard Library functions that are string-related have to assume that the pointer you pass will be a pointer to a null terminated array. Those Standard Library functions could have been set up so that they accept a length argument... and in fact, some functions do accept/require a length element. strncpy() is one such function.

      C is perfectly fine. The C Standard Library could use some

  • So create standards-compliant functions MickeySoft (Score:4, Informative)

    by Anonymous Coward on Monday February 11, 2019 @03:32PM (#58105866)

    The C Standard added Annex K, Bounds-checking Interfaces [port70.net] 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 [open-std.org]

    ...

    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.

  • Why they do not have that under control is puzzling. Well, not really, this is MS, after all.

  • MS's Jim Allchin... (Score:3)

    by QuietLagoon ( 813062 ) on Monday February 11, 2019 @03:43PM (#58105972)
    ... 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 is not new (Score:4, Interesting)

    by MobyDisk ( 75490 ) on Monday February 11, 2019 @03:54PM (#58106060) Homepage

    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.

  • 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

    • Re: (Score:2)

      by jma05 ( 897351 )

      This is mostly a strawman.
      None of those languages were ever considered real candidates for OS or driver development, except Rust (which generates the same machine code with safer high-level constructs).

      As much as I dislike C, I am fine with it for kernel and driver development. C can be mostly safe IF you pour a lot of human resources to review it. People always assume they are better at things than they actually are... and with C that is more of a problem.

      Not all that makes an OS and presents vulnerabiliti

      • Re: (Score:2)

        by ledow ( 319597 )

        That there isn't a mainstream, popular, memory-safe language that is suitable for writing an OS (to the point that *anyone* from the entire tech industry has written an OS in it that's mainstream/popular in itself?) is a strawman?

        No, that's my exact point.

        Any language is an expression of your intention. If your intentions are poorly thought out, planned, described and executed, that's a fault common to all languages and little can fix that (expecting the "grammar" or "vocabulary" of a particular language t

        • Re: (Score:2)

          by jma05 ( 897351 )

          No, the strawman is pointing to scripting languages like Python and Javascript and saying they won't cut it for writing an OS. Of course, they don't. Who is even suggesting?

          Again, I am not arguing against use of C for kernels. I am arguing against using C style programming (trusting humans with transparent memory access) unless it is absolutely warranted.

          I am also not getting the sense that you properly tried Rust yet.

          https://ruudvanasseldonk.com/2... [ruudvanasseldonk.com]

          It does do safer constructs with no extra cost. It does s

  • Microsoft knows everything there is to know about buggy software.

  • Should (Score:3)

    by AHuxley ( 892839 ) on Monday February 11, 2019 @06:54PM (#58107042) Journal
    have made an Ada OS.
  • “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 peopl

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close