A reactionary take on memory safety

https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-safety

by zdw • 2 years ago

42 59 2 years ago

lcamtuf.substack.com

alephnerd2• 2 years 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.

timeon2• 2 years 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• 2 years ago

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

alephnerd2• 2 years 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".

kevingadd4• 2 years 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.)

timeon2• 2 years ago

But that is the point of memory safe languages. You can shift priority to non-memory safety issues.

pornel2• 2 years 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.

im3w1l4• 2 years 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• 2 years 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.

secondcoming2• 2 years ago

And programming becomes a licenced profession!

marcosdumay2• 2 years ago

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.

kevingadd4• 2 years 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.

reanimus2• 2 years 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• 2 years 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?"

kbolino11• 2 years 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.

tyfighter• 2 years ago

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.

kevingadd4• 2 years ago

I don't understand how this justifies writing off the work of security professionals as not real work or not difficult. Is the author talking about people who run security scanner scripts and call it a day? If so, why are those people relevant to discussions of memory safety and why generalize the entire discipline based on them? Are we supposed to generalize the traits/experiences of the average PHP developer and apply that to Haskell and C++ experts too? Every field has lazy people or unskilled hacks in it.

Some subset of the industry having "bad opinions" also does not mean their work suddenly has no value or they're not trying hard. To me this approach to the hard work of real experts is immediately disqualifying for someone's opinions. They can think it, but if they want to say it they should be prepared to not be taken seriously.

kbolino11• 2 years 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.

im3w1l4• 2 years 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.

kbolino11• 2 years 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++.

gpderetta2• 2 years ago

Or you if you flip the correct compiler flags.

packetlost• 2 years ago

C++ is so large that choosing the safe subset is completely non-obvious unless you're deeply experience in the language already.

bombcar2• 2 years ago

And with similar knowledge and care, C can also be safe; after all, memory safe languages can be written in C.

secondcoming2• 2 years ago

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.

jerf2• 2 years 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

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.

kbolino11• 2 years 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• 2 years 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.

tsegratis2• 2 years ago

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• 2 years ago

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.

jerf2• 2 years ago

That's not a contrarian take, because it's just not relevant. "C and C++ seem to work" is not the question at issue.

Moreover, C and C++ are the world we live in in which CVEs flow like water, where our systems crash routinely, where we have the problems that are making us have this discussion in the first place.

If you think this is all just fantastic, that there isn't any option of doing better, we just have to live with the effects of memory unsafety, and there's no point even trying to improve the quality of our base level tools, then honestly all I can say to such a battered spouse syndrome sufferer is that we're going to have to agree to disagree.

o11c4• 2 years 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!

kbolino11• 2 years 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.

o11c4• 2 years 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.

Gibbon1• 2 years ago

unions would be better if C had first class types.

C would be safer if it had memory safe casts.

C would be safer if we forced compilers to implement Walter Brights suggestion about array arguments.

C would be better if it had stdslice.h

Programs would be safer if the cultural prohibition against passing and returning structs was exterminated.

kbolino11• 2 years ago

Programs would be safer if the cultural prohibition against passing and returning structs was exterminated.

The lack of a single, dominant, consistently high-quality C compiler likely caused this problem. As long as `int foo(struct{int x; int y})` doesn't optimize down to `int foo(int x, int y)` there are significant performance issues with struct passing. The return situation is especially problematic since C doesn't have multiple-valued return to begin with, so structs become a special case.

andrewstuart2• 2 years 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 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.

znkr2• 2 years 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/mas...

To quote from those slides: „~70% of the vulnerabilities addressed through a security update each year continue to be memory safety issues“.

andrewstuart2• 2 years ago

You didn’t read the linked article.

It directly attributes Matt Miller.

And the point is that this percentage quoted is the flaws in Microsoft products, not all security vulnerabilities as is falsely claimed.

LAC-Tech• 2 years 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.

A reactionary take on memory safety

Related Stories