[HN Gopher] A reactionary take on memory safety
___________________________________________________________________
A reactionary take on memory safety
Author : zdw
Score : 33 points
Date : 2024-03-02 02:43 UTC (20 hours ago)
(HTM) web link (lcamtuf.substack.com)
(TXT) w3m dump (lcamtuf.substack.com)
| alephnerd wrote:
| 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.
| kelseyfrog wrote:
| How is this not a clear example of the Shirky Principle?
| Institutions try to preserve the problem to which they are the
| solution?
| alephnerd wrote:
| 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 wrote:
| 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 wrote:
| The article recognizes this: "the primary attack surface is
| limited chiefly to network stacks, browser APIs, and a
| handful of multimedia transcoding libraries."
| pornel wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| secondcoming wrote:
| And programming becomes a licenced profession!
| marcosdumay wrote:
| > Memory unsafe? No government contract for you!
|
| That's exactly what the GP pointed that isn't on the memo.
|
| But if you insist on using unsafe languages, and not using
| any of the tools and procedures available for making those
| safer, then yes, no contract money for you, and no insurance
| if something happens.
| im3w1l wrote:
| It may not be in the memo, but I do think it's coming, at
| some point.
| kbolino wrote:
| A lot of contracting is just developing to spec and/or
| working directly on-site just like regular employees. The
| government is going to have to dogfood this approach
| inasmuch as they want this to work.
| kevingadd wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kbolino wrote:
| 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.
| tyfighter wrote:
| No, you're not getting it. The reverse engineering itself is
| obviously extremely difficult work, but it's the work of an
| individual or at best a small team. Reverse engineering work
| only provides existence proofs of security issues, mostly
| singular instances. Taken to its extreme, some reverse
| engineers believe this means that all memory unsafe software
| needs to be rewritten. The sheer amount of software written in
| C or C++ dwarfs the size of the reverse engineering community
| in amounts I can't even fathom.
| kbolino wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _GLIBCXX_ASSERTIONS which is explicitly intended to be
| enabled for production builds.
| gpderetta wrote:
| Or you if you flip the correct compiler flags.
| packetlost wrote:
| C++ is so large that choosing the safe subset is completely
| non-obvious unless you're deeply experience in the language
| already.
| bombcar wrote:
| And with similar knowledge and care, C can also be safe;
| after all, memory safe languages can be written in C.
| kbolino wrote:
| Yeah, my thought/question is more about doing so
| ergonomically. Because C++ has encapsulation and operator
| overloading, you _can_ make it very ergonomic to write
| memory-safe code.
|
| I think it's very difficult to do the same with plain C.
| It's probably possible to make it less painful with macros,
| but doing so builds something more like a DSL atop of C,
| and would frustrate IDEs that don't understand the
| conventions.
| MaxBarraclough wrote:
| > C can also be safe
|
| In practical terms, no, it cannot. Even C codebases held to
| very high standards tend to have memory-safety issues.
|
| > memory safe languages can be written in C
|
| That says nothing about the safety of the C language.
| secondcoming wrote:
| These days it's surprisingly hard to write memory-unsafe C++
| code for not-so-trivial programs. There are still things that
| can trip you up, like views.
| jerf wrote:
| 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
|
| 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 wrote:
| 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 wrote:
| 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.
| tsegratis wrote:
| Allow me to be contrarian
|
| Hard to count, but, excluding webapps, maybe 98% (or more) of
| generally used software has a basis in c/c++. Your fridge,
| watch, computer, car, phone. clang, gcc, photoshop, your
| browser, almost any desktop app, your 3d games. The remaining
| 2% (or less), is maybe even majority written in assembly,
| forth, etc, in your calculator and toaster
|
| So to agree with you, I would need an explanation of why such
| wispy benefits led to such a large effect
|
| Oberon existed, pascal, ada, they are excellent and safe, why
| then were they not popular?
|
| Note: Easy to disagree with that percentage, but the effect is
| enormous, and as far as I understand, not explained by the
| current bandwagon
| Jtsummers wrote:
| Politics and price. C and Unix were free, other options were
| not. Oberon is also unsuitable for most use-cases if taken to
| Wirth's extreme, though the other variations are better they
| were still very niche (also it was never exactly well-known
| or well-distributed). With Pascal, which Pascal? The early
| Pascal's needed extensions (leading to the Modula line and
| Delphi ultimately). They also tended to cost, people like
| free. Politics are why Ada lost, along with costs. Ada, as a
| mandatory language for a time in DOD, had a compelled
| audience with "deep" (not always that deep) pockets who could
| afford $10k/seat licenses (or more), that didn't make it a
| suitable language for the *nix hackers of the 90s and Linux
| (in particular) has eaten the world.
|
| So C and C++ won out as the systems languages. Not because of
| quality, but price and politics.
|
| EDIT: I mean Unix broadly, there were obviously non-free
| commercial Unixes.
| o11c wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| andrewstuart wrote:
| 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 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-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-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.
| LAC-Tech wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-02 23:01 UTC)