https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-safety [https] lcamtuf's thing Subscribe Sign in Share this post [https] A reactionary take on memory safety lcamtuf.substack.com Copy link Facebook Email Note Other A reactionary take on memory safety Mar 1, 2024 13 Share this post [https] A reactionary take on memory safety lcamtuf.substack.com Copy link Facebook Email Note Other 7 Share I was there when the universe formed: back in the 1990s, when information security wasn't a reputable occupation, when case law was scant, and when every system could be breached at will. In the chaos, I saw an opportunity -- and I dedicated a good portion of my adult life to helping others stay clear of online risks. Throughout the years, one of the enduring problems I wrestled with was memory safety. For folks unfamiliar with the term, it boils down to programming languages such as C and C++ not keeping track of the memory allocated to the program and not preventing access out of bounds. This gives rise to endemic coding errors such as buffer overflows or use-after-free. With a bit of luck and skill, a subset of these bugs can corrupt program control structures and allow attackers to perform actions they're not otherwise authorized to perform. Today, there is a growing chorus of voices in the information security community positing that memory safety is the most consequential battle of our times; the latest salvo in this debate is the guidance published by The White House, urging the adoption of memory-safe languages across the industry. For many, a non-binding document does not go far enough: perhaps the government ought to outlaw C and C++ altogether, be it for federal contracts or for any infrastructure deemed critical. This puts me in an awkward position: after all these years fighting for memory safety, I'm disagreeing with the proposal to end it once and for all. 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. This proposal -- demanding that developers re-learn their craft -- certainly fits that mold. My more pragmatic critique is that I doubt it's worth the cost. First, only a small fraction of memory-unsafe code is realistically exposed to attacks. In the context of modern computing paradigms, the primary attack surface is limited chiefly to network stacks, browser APIs, and a handful of multimedia transcoding libraries. Together, these components probably represent less than 10% of the codebase targeted by the proposed mandates; and perhaps 2% is of major economic interest. Further, thanks to the decades of work on low-overhead exploit mitigations -- notably including address space randomization and branch tracking -- successful exploitation of memory safety issues has gotten quite challenging and accounts only for a tiny sliver of the overall volume of security incidents. Although memory corruption bugs are favored by some government actors, virtually all large-scale breaches trace back to other issues: outdated or misconfigured software, phishing, and so on. Finally, I'm skeptical that a nonspecific mandate to adopt memory-safe languages will necessarily nudge developers in the right direction; for every restrictive language designed with security in mind, there are dozens of memory-safe choices that on balance, introduce more bugs. In this context, the woes associated with PHP, SQL, and JavaScript are of special note; the trio is popular for good reasons, but is probably responsible for more harm than C and C++. Migrations to languages such as Python and Java might be marginally beneficial, but come with a lot of baggage too. Together, these observations make me doubt that migrating organizations to memory-safe languages is a worthwhile intervention today. If we could wave a magic wand to transmogrify all C and C++ into Rust, I wouldn't bat an eye -- although I doubt it'd alter the landscape of information security in a profound way. Still, in a reality where even simply keeping track of your hardware and software assets is a formidable challenge for most enterprises, I think that the push for 100% memory safety is a grievous misallocation of funds. [ ] Subscribe 13 Share this post [https] A reactionary take on memory safety lcamtuf.substack.com Copy link Facebook Email Note Other 7 Share 7 Comments [https] [ ] Share this discussion [https] A reactionary take on memory safety lcamtuf.substack.com Copy link Facebook Email Note Other nothacking Mar 1 Most memory safety exploits will break with even a tiny modification to the program or system. Most logic and API/ [https] serialization bugs are much easier to exploit, and are much more portable. For example, the same payload that works for Apache servers will also work if sent in *minecraft* chat. Expand full comment Reply Share Ben Mar 1 Strong agree. When Cyclone was blazing a trail in memory safe systems language design 20+ years ago, it seemed like an exciting step forward. But in addition to the mitigations you [https] mentioned, sanitizers, fuzz testing and better idioms in C++ have all made it far more practical to develop pretty darn safe code in C/C++ than it was a generation ago. Expand full comment Reply Share 5 more comments... Top New Community No posts Ready for more? [ ] Subscribe (c) 2024 lcamtuf Privacy [?] Terms [?] Collection notice Start WritingGet the app Substack is the home for great writing This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts