6 ms·

A reactionary take on memory safety

42 points by zdw 3y ago

alephnerd 3y ago
THANK YOU! Don't get me wrong, memory safety is a vector, but can be remediated against with stronger platform architecture (eg. Network Access Control, Identity Management, Asset Governance), which is where most companies stumble. Having a memory safe application doesn't matter if you didn't properly segment your environment so a misconfigured IoT had open external and internal access.
- timeon 3y ago
  Point is that with memory safe language you can actually focus on the issues you have described more. Because there is one less thing to worry about [0]. [0] not really but scope is contained.
kelseyfrog 3y ago
How is this not a clear example of the Shirky Principle? Institutions try to preserve the problem to which they are the solution?
- alephnerd 3y ago
  Companies have finite resources. There is a reason vulnerabilities come with Vulnerability Scores and Risk Assessment. Memory based attacks just aren't a relevant enough vector compared to other lower hanging fruit like misconfigurations or lax resource governance. This isn't to say memory attacks aren't a vector (they absolutely are), but deciding which vector is higher priority is heavily organization dependent. Also, the Shirky's Principle is pop business "knowledge" like the "Conjoined Triangles of Success" or the "Hype Cycle".
  - kevingadd 3y ago
    Everyone says memory attacks aren't relevant until one gets used to build an exploit chain that's remotely triggered to hack your phone by sending you an SMS message. (This specific example has, iirc, happened multiple times.)
    - discreteevent 3y ago
      The article recognizes this: "the primary attack surface is limited chiefly to network stacks, browser APIs, and a handful of multimedia transcoding libraries."
      - wtetzner 3y ago
        That's not really true though. Any software that is in some way accessible over the network is a problem (which is the vast majority of software).
  - timeon 3y ago
    But that is the point of memory safe languages. You can shift priority to non-memory safety issues.
- deleted 3y ago
  [deleted]
pornel 3y ago
This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++. It even explicitly notes complete rewrites are too challenging! The memo is quite broad, and goes beyond just the language choice. It also gives formal verification and CHERI as options for mitigating language unsafety. It refers to NSA's plan that goes even further into mitigations for existing codebases. The article also rides on the contempt for PHP to make migration from C/C++ sound stupid, but PHP is not a real contender for systems programming, and isn’t on the list of recommended memory safe languages. It’s a “but what about all the other bugs”, as if having memory unsafety bugs somehow prevented all other kinds of bugs. It plays on the trope that real programmers use C++, and won't write bugs like the amateurs using blub languages. The memo recognizes that CVE counting is problematic and calls for research into better vulnerability tracking and evaluation to get a better picture of actual risks, and address overall quality issues, not just memory safety.
- im3w1l 3y ago
  > This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++. Maybe not outlaw, but I think in the long term the outcome will be similar. Memory unsafe? No government contract for you! Credit cards details leaked? Well not being memory safe was negligent, no insurance payout for you. I think eventually all criticial infrastructure (including their dependencies, including libraries but also OS) will be be basically required to be memory safe.
  - l33t7332273 3y ago
    All OS’s being required to be memory safe would mean some major changes to linux that I just don’t see a path to from today.
    - bombcar 3y ago
      Iirc it would affect all current OSes except maybe some experimental/toy ones. Ring 0 may get smaller and smaller but it’s still there.
  - 3y ago
kevingadd 3y ago
"For one, I think that security professionals are too keen to collect paychecks for bossing people around and having others do all the hard work." Anyone who's read more than a few write ups of exploit chains wouldn't post something this ignorant. I'm not sure how to interpret this whole post in good faith unless it's satire. Just go read some posts off project zero.
- reanimus 3y ago
  Yeah, lines like that belie a contempt for security professionals and the work they do that paints the rest of the argument in a different light.
  - er4hn 3y ago
    lcamtuf _is_ a security professional. He created p0f, AFL, wrote Silence on the Wire, and has done cybersec jobs from engineering to executive leadership. He has taken to posting mildly trollish stuff ("poasting") on Xitter, but this seems like a well reasoned reply to "Is rewriting entire codebases in a different language worth it?"
    - reanimus 3y ago
      You can argue whether or not the contempt is justified, but if your default position towards others in your field is "they're incompetent and just want to generate work for others", I'll be taking what you say regarding whether or not a given thing is worth working on with a grain of salt.
    - kevingadd 3y ago
      This is valuable context for the post, so thank you for explaining who the author is. It makes his stance on his colleagues all the more confusing though and I can only interpret the post as trolling. At least they're informed opinions, so I can understand why it got posted here.
  - kbolino 3y ago
    Sadly, 90% of "security professionals" give the rest a bad name. Unfortunately, for whatever reasons, large bureaucracies seem to have decided that, after doing the same thing to network engineering and systems administration, computer security is just a dump profession in which you put slightly dim people who are only good at repeating mantras. For every pen tester or true security expert who breaks things for fun in their spare time, I've run into far too many more of the "just make the vulnerability scanner turn green" type. It's quite unfair actually that they get lumped together.
kbolino 3y ago
I admittedly don't write much C++ and what I do know is largely limited to C++03. But it does flummox me a bit that C++ keeps getting lumped in with C. Aren't `std::vector` and `std::string` bounds-checked? Isn't it possible, though perhaps not always obvious or ergonomic, to write memory-safe C++ code? It seems like improving static validation tools might be more useful than trying to phase out C++. I also think the build system and dependency management could probably use at least as much attention as memory safety, though maybe there's some convention that's emerged lately which brings it in line with more recent languages.
- im3w1l 3y ago
  std::vector is bounds checked if you use .at() instead of operator[]. But it's less ergonomic and I don't think people typically use that.
  - kbolino 3y ago
    Good point. I would think you could make operator[] bounds-checked with an opt-in mechanism like a #define but I don't know if such a thing exists and I would assume it could cause unpredictable behavior in code not designed to handle exceptions. Thinking about this example, it seems like the other problem is that even when bounds-checked, C++ code handles out-of-bounds conditions by throwing exceptions, which seem to have a bad rap in C++.
    - gpderetta 3y ago
      _GLIBCXX_ASSERTIONS which is explicitly intended to be enabled for production builds.
    - im3w1l 3y ago
      I actually disagree with that. Exceptions have their problems when used for error handling, but they are a great solution for error not-handling, and normally index out of bounds is a bug that you can't / don't want to recover from. Exceptions will bubble up and unwind the stack, cleaning things up by running destructors. In other languages they will also display a nice little backtrace, though in c++ it seems thats not typically done for reasons that are beyond me.
deleted 3y ago
[deleted]
jerf 3y ago
I posted something three days ago about memory safety that I feel like basically could be echoed here: https://news.ycombinator.com/item?id=39542875 https://news.ycombinator.com/item?id=39542875 Albeit modulated since I'm sure lcamtuf is not actively advocating for memory unsafety the way I'm sure some people are. But I don't understand why anyone is bothering to state any objections to memory safety. Modulo the issue of old code bases in memory unsafe languages that can not be simply discarded or rewritten... I personally have done translation projects between languages, I am well aware of the costs involved and freely acknowledge them... there simply isn't any argument in favor of memory unsafety. There's no benefit to having memory unsafety around. If anything memory safety is a positive benefit, or to put it another way, programming in a memory unsafe language is positively harder than a memory safe language. The proof of this is the existence of the "unsafe" package/module/library/whatever that exists in your language, meaning that you can selectively call out to it whenever you do in fact need to. That means the rest of the time you don't. So why give any cover to memory unsafe languages? There's simply no argument for them. You do not need a language that lets you access outside of array bounds. You do not need a language that lets you run a pointer everywhere without regard for bounds. Even if you need bounds check removed or something, you only need it in a particular tight loop, not pervasively throughout your language. There is nothing, no positive advantage they offer that overcomes the overwhelming, massive costs they've concretely imposed on society as a whole. And I'm Mr. Everything Has Costs And Benefits. But the benefits are so, so wispy here and the costs so large and concrete.
- kbolino 3y ago
  I don't think you're wrong but I do think putting all the burden and emphasis on the last mile (high-level software libraries and application software) will not be enough. Memory safety needs better support from operating systems and hardware, both of which have improved but have been much slower to change than application programming. Systems programming, sitting in the middle of the two, is caught between a rock and a hard place.
- skywhopper 3y ago
  The point is that rewrites are costly and introduce new bugs. New software written in safe languages to replace old software will inevitably introduce new bugs and repeat old ones. That’s not a reason against using memory safe languages, but the danger is that a too-keen focus on memory safety risks devaluing other, far cheaper means of improving security. Yes, use memory-safe languages for new projects. But don’t lie to yourself and everyone else and say that they will come anywhere close to making a significant dent in the rate of security bugs.
o11c 3y ago
The real problem is that people keep on inventing new memory safe languages that no longer support many of the widely-used features of C. Ignore efficiency and all that. If you don't support `union` and `va_list`, you're never going to replace C. It's okay to mark them as deprecated, but you need to support them to provide a migration path. The fact that C allows hand-written `memcpy`-style loops is another major concern in theory, but it is one that is much easier to port. Laundering pointers through non-process memory is rare enough that an explicit API is reasonable to require. And yes, it is possible to support all these things with perfect dynamic memory safety and without increasing pointer size!
- kbolino 3y ago
  > And yes, it is possible to support all these things with perfect dynamic memory safety and without increasing pointer size! You had me up to this point. A memory-safe union is a discriminated union, which needs extra information (a discriminator) to tell which case is currently active. That doesn't necessarily increase pointer size, but it does break ABI compatibility.
  - o11c 3y ago
    You don't have to store that in-line, you can store it in metadata. Kind of like how ASAN works, but with typing info instead of just validity info. Now yes, for performance you don't want to do this ... but it can be just one step of the migration.
    - kbolino 3y ago
      If you're able to accept ABI breakage or changing the C code, then I don't think any major language which is capable of calling C code is missing support for unions. The same cannot be said for varargs, though.
      - o11c 3y ago
        I explicitly refer to untagged unions though, not tagged ones. The lack of a language-known tag is part of the API, not just the ABI. Even library-specific tags should only be considered an incremental upgrade, not the core union support. Yes, it is possible to refactor things like `SDL_Event` to use subclasses instead of unions. But the point is - you shouldn't have to, not at first. And of course, you need to be able to use a union to perform a bitwise cast between float and int. Not some other ad-hoc API; it needs to be trivial to port from C regardless of what the context looks like.
andrewstuart 3y ago
The whole memory safety thing is based on a falsehood. Memory safety is where it is because of misquotes and misinterpretations. Here are the incorrect quotes: "70% of all security vulnerabilities were caused by memory safety issues" https://en.wikipedia.org/wiki/Memory_safety https://en.wikipedia.org/wiki/Memory_safety In 2019, a Microsoft security engineer reported that 70% of all security vulnerabilities were caused by memory safety issues. In 2020, a team at Google similarly reported that 70% of all "severe security bugs" in Chromium were caused by memory safety problems. "Microsoft: 70 percent of all security bugs are memory safety issues " https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... The actual quote from Matt Miller is this (quoted from the SAME article that has a false headline above) https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... "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." So it is FALSE that "70% of all security vulnerabilities were caused by memory safety issues". What Matt Miller said is that "70% of all Microsoft patches were fixes for memory safety bugs" - that is VERY different. As a result, the fiction that "70% of all security vulnerabilities were caused by memory safety issues" has become real to many people thus they are focusing their security effort on memory safety when that is not even the primary security issue and certainly not 70% of all security issues.
- znkr 3y ago
  You’ll find more primary sources across different organizations that all arrive at the 60 - 70% number. But what really grinds my gears here is that you take a piece from the article you’re criticizing and pretend that it’s a quote from Matt Miller. It’s actually quite easy to find a primary source here because the slides from the talk that the article is based on are available: https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas... To quote from those slides: „~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues“.
LAC-Tech 3y ago
My completely anecdotal and unscientific impression is that rust is on the upwards trends, mandate or not. Does anyone in 2024 still want to make a greenfield C++ project? I don't. Nothing really to do with memory safety, it's mainly just tooling.
scarlettjoe22 3y ago
[dead]

42 points by zdw 3y ago

THANK YOU! Don't get me wrong, memory safety is a vector, but can be remediated against with stronger platform architecture (eg. Network Access Control, Identity Management, Asset Governance), which is where most companies stumble. Having a memory safe application doesn't matter if you didn't properly segment your environment so a misconfigured IoT had open external and internal access.

timeon 3y ago
Point is that with memory safe language you can actually focus on the issues you have described more. Because there is one less thing to worry about [0]. [0] not really but scope is contained.

kelseyfrog 3y ago

How is this not a clear example of the Shirky Principle? Institutions try to preserve the problem to which they are the solution?

alephnerd 3y ago
Companies have finite resources. There is a reason vulnerabilities come with Vulnerability Scores and Risk Assessment. Memory based attacks just aren't a relevant enough vector compared to other lower hanging fruit like misconfigurations or lax resource governance. This isn't to say memory attacks aren't a vector (they absolutely are), but deciding which vector is higher priority is heavily organization dependent. Also, the Shirky's Principle is pop business "knowledge" like the "Conjoined Triangles of Success" or the "Hype Cycle".
- kevingadd 3y ago
  Everyone says memory attacks aren't relevant until one gets used to build an exploit chain that's remotely triggered to hack your phone by sending you an SMS message. (This specific example has, iirc, happened multiple times.)
  - discreteevent 3y ago
    The article recognizes this: "the primary attack surface is limited chiefly to network stacks, browser APIs, and a handful of multimedia transcoding libraries."
    - wtetzner 3y ago
      That's not really true though. Any software that is in some way accessible over the network is a problem (which is the vast majority of software).
- timeon 3y ago
  But that is the point of memory safe languages. You can shift priority to non-memory safety issues.
deleted 3y ago
[deleted]

pornel 3y ago

This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++. It even explicitly notes complete rewrites are too challenging! The memo is quite broad, and goes beyond just the language choice. It also gives formal verification and CHERI as options for mitigating language unsafety. It refers to NSA's plan that goes even further into mitigations for existing codebases. The article also rides on the contempt for PHP to make migration from C/C++ sound stupid, but PHP is not a real contender for systems programming, and isn’t on the list of recommended memory safe languages. It’s a “but what about all the other bugs”, as if having memory unsafety bugs somehow prevented all other kinds of bugs. It plays on the trope that real programmers use C++, and won't write bugs like the amateurs using blub languages. The memo recognizes that CVE counting is problematic and calls for research into better vulnerability tracking and evaluation to get a better picture of actual risks, and address overall quality issues, not just memory safety.

im3w1l 3y ago
> This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++. Maybe not outlaw, but I think in the long term the outcome will be similar. Memory unsafe? No government contract for you! Credit cards details leaked? Well not being memory safe was negligent, no insurance payout for you. I think eventually all criticial infrastructure (including their dependencies, including libraries but also OS) will be be basically required to be memory safe.
- l33t7332273 3y ago
  All OS’s being required to be memory safe would mean some major changes to linux that I just don’t see a path to from today.
  - bombcar 3y ago
    Iirc it would affect all current OSes except maybe some experimental/toy ones. Ring 0 may get smaller and smaller but it’s still there.
- 3y ago

kevingadd 3y ago

"For one, I think that security professionals are too keen to collect paychecks for bossing people around and having others do all the hard work." Anyone who's read more than a few write ups of exploit chains wouldn't post something this ignorant. I'm not sure how to interpret this whole post in good faith unless it's satire. Just go read some posts off project zero.

reanimus 3y ago
Yeah, lines like that belie a contempt for security professionals and the work they do that paints the rest of the argument in a different light.
- er4hn 3y ago
  lcamtuf _is_ a security professional. He created p0f, AFL, wrote Silence on the Wire, and has done cybersec jobs from engineering to executive leadership. He has taken to posting mildly trollish stuff ("poasting") on Xitter, but this seems like a well reasoned reply to "Is rewriting entire codebases in a different language worth it?"
  - reanimus 3y ago
    You can argue whether or not the contempt is justified, but if your default position towards others in your field is "they're incompetent and just want to generate work for others", I'll be taking what you say regarding whether or not a given thing is worth working on with a grain of salt.
  - kevingadd 3y ago
    This is valuable context for the post, so thank you for explaining who the author is. It makes his stance on his colleagues all the more confusing though and I can only interpret the post as trolling. At least they're informed opinions, so I can understand why it got posted here.
- kbolino 3y ago
  Sadly, 90% of "security professionals" give the rest a bad name. Unfortunately, for whatever reasons, large bureaucracies seem to have decided that, after doing the same thing to network engineering and systems administration, computer security is just a dump profession in which you put slightly dim people who are only good at repeating mantras. For every pen tester or true security expert who breaks things for fun in their spare time, I've run into far too many more of the "just make the vulnerability scanner turn green" type. It's quite unfair actually that they get lumped together.

kbolino 3y ago

I admittedly don't write much C++ and what I do know is largely limited to C++03. But it does flummox me a bit that C++ keeps getting lumped in with C. Aren't `std::vector` and `std::string` bounds-checked? Isn't it possible, though perhaps not always obvious or ergonomic, to write memory-safe C++ code? It seems like improving static validation tools might be more useful than trying to phase out C++. I also think the build system and dependency management could probably use at least as much attention as memory safety, though maybe there's some convention that's emerged lately which brings it in line with more recent languages.

im3w1l 3y ago
std::vector is bounds checked if you use .at() instead of operator[]. But it's less ergonomic and I don't think people typically use that.
- kbolino 3y ago
  Good point. I would think you could make operator[] bounds-checked with an opt-in mechanism like a #define but I don't know if such a thing exists and I would assume it could cause unpredictable behavior in code not designed to handle exceptions. Thinking about this example, it seems like the other problem is that even when bounds-checked, C++ code handles out-of-bounds conditions by throwing exceptions, which seem to have a bad rap in C++.
  - gpderetta 3y ago
    _GLIBCXX_ASSERTIONS which is explicitly intended to be enabled for production builds.
  - im3w1l 3y ago
    I actually disagree with that. Exceptions have their problems when used for error handling, but they are a great solution for error not-handling, and normally index out of bounds is a bug that you can't / don't want to recover from. Exceptions will bubble up and unwind the stack, cleaning things up by running destructors. In other languages they will also display a nice little backtrace, though in c++ it seems thats not typically done for reasons that are beyond me.

deleted 3y ago

[deleted]

jerf 3y ago

I posted something three days ago about memory safety that I feel like basically could be echoed here: https://news.ycombinator.com/item?id=39542875 https://news.ycombinator.com/item?id=39542875 Albeit modulated since I'm sure lcamtuf is not actively advocating for memory unsafety the way I'm sure some people are. But I don't understand why anyone is bothering to state any objections to memory safety. Modulo the issue of old code bases in memory unsafe languages that can not be simply discarded or rewritten... I personally have done translation projects between languages, I am well aware of the costs involved and freely acknowledge them... there simply isn't any argument in favor of memory unsafety. There's no benefit to having memory unsafety around. If anything memory safety is a positive benefit, or to put it another way, programming in a memory unsafe language is positively harder than a memory safe language. The proof of this is the existence of the "unsafe" package/module/library/whatever that exists in your language, meaning that you can selectively call out to it whenever you do in fact need to. That means the rest of the time you don't. So why give any cover to memory unsafe languages? There's simply no argument for them. You do not need a language that lets you access outside of array bounds. You do not need a language that lets you run a pointer everywhere without regard for bounds. Even if you need bounds check removed or something, you only need it in a particular tight loop, not pervasively throughout your language. There is nothing, no positive advantage they offer that overcomes the overwhelming, massive costs they've concretely imposed on society as a whole. And I'm Mr. Everything Has Costs And Benefits. But the benefits are so, so wispy here and the costs so large and concrete.

kbolino 3y ago
I don't think you're wrong but I do think putting all the burden and emphasis on the last mile (high-level software libraries and application software) will not be enough. Memory safety needs better support from operating systems and hardware, both of which have improved but have been much slower to change than application programming. Systems programming, sitting in the middle of the two, is caught between a rock and a hard place.
skywhopper 3y ago
The point is that rewrites are costly and introduce new bugs. New software written in safe languages to replace old software will inevitably introduce new bugs and repeat old ones. That’s not a reason against using memory safe languages, but the danger is that a too-keen focus on memory safety risks devaluing other, far cheaper means of improving security. Yes, use memory-safe languages for new projects. But don’t lie to yourself and everyone else and say that they will come anywhere close to making a significant dent in the rate of security bugs.

o11c 3y ago

The real problem is that people keep on inventing new memory safe languages that no longer support many of the widely-used features of C. Ignore efficiency and all that. If you don't support `union` and `va_list`, you're never going to replace C. It's okay to mark them as deprecated, but you need to support them to provide a migration path. The fact that C allows hand-written `memcpy`-style loops is another major concern in theory, but it is one that is much easier to port. Laundering pointers through non-process memory is rare enough that an explicit API is reasonable to require. And yes, it is possible to support all these things with perfect dynamic memory safety and without increasing pointer size!

kbolino 3y ago
> And yes, it is possible to support all these things with perfect dynamic memory safety and without increasing pointer size! You had me up to this point. A memory-safe union is a discriminated union, which needs extra information (a discriminator) to tell which case is currently active. That doesn't necessarily increase pointer size, but it does break ABI compatibility.
- o11c 3y ago
  You don't have to store that in-line, you can store it in metadata. Kind of like how ASAN works, but with typing info instead of just validity info. Now yes, for performance you don't want to do this ... but it can be just one step of the migration.
  - kbolino 3y ago
    If you're able to accept ABI breakage or changing the C code, then I don't think any major language which is capable of calling C code is missing support for unions. The same cannot be said for varargs, though.
    - o11c 3y ago
      I explicitly refer to untagged unions though, not tagged ones. The lack of a language-known tag is part of the API, not just the ABI. Even library-specific tags should only be considered an incremental upgrade, not the core union support. Yes, it is possible to refactor things like `SDL_Event` to use subclasses instead of unions. But the point is - you shouldn't have to, not at first. And of course, you need to be able to use a union to perform a bitwise cast between float and int. Not some other ad-hoc API; it needs to be trivial to port from C regardless of what the context looks like.

andrewstuart 3y ago

The whole memory safety thing is based on a falsehood. Memory safety is where it is because of misquotes and misinterpretations. Here are the incorrect quotes: "70% of all security vulnerabilities were caused by memory safety issues" https://en.wikipedia.org/wiki/Memory_safety https://en.wikipedia.org/wiki/Memory_safety In 2019, a Microsoft security engineer reported that 70% of all security vulnerabilities were caused by memory safety issues. In 2020, a team at Google similarly reported that 70% of all "severe security bugs" in Chromium were caused by memory safety problems. "Microsoft: 70 percent of all security bugs are memory safety issues " https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... The actual quote from Matt Miller is this (quoted from the SAME article that has a false headline above) https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... "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." So it is FALSE that "70% of all security vulnerabilities were caused by memory safety issues". What Matt Miller said is that "70% of all Microsoft patches were fixes for memory safety bugs" - that is VERY different. As a result, the fiction that "70% of all security vulnerabilities were caused by memory safety issues" has become real to many people thus they are focusing their security effort on memory safety when that is not even the primary security issue and certainly not 70% of all security issues.

znkr 3y ago
You’ll find more primary sources across different organizations that all arrive at the 60 - 70% number. But what really grinds my gears here is that you take a piece from the article you’re criticizing and pretend that it’s a quote from Matt Miller. It’s actually quite easy to find a primary source here because the slides from the talk that the article is based on are available: https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas... To quote from those slides: „~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues“.

LAC-Tech 3y ago

My completely anecdotal and unscientific impression is that rust is on the upwards trends, mandate or not. Does anyone in 2024 still want to make a greenfield C++ project? I don't. Nothing really to do with memory safety, it's mainly just tooling.

scarlettjoe22 3y ago

[dead]