Memory safety is the new black, fashionable and fit for any occasion
- Reference: 1674745265
- News link: https://www.theregister.co.uk/2023/01/26/memory_safety_mainstream/
- Source link:
Consumer Reports, an 87-year-old nonprofit focused on product testing, this week published [1]a report on memory safety. The publication acknowledged its unexpected coverage of the topic by explaining how it came to explore this highly technical concern after internal conversations about the limitations of its consumer-focused guide to online security.
The topic came up on Wednesday [2]at the USENIX Enigma 2023 conference , where panelists Yael Grauer (deputy content editor, Consumer Reports Digital Lab), Amira Dhalla (associate director of mobilizations, community engagement, and operations at Consumer Reports), Alex Gaynor (software security engineer and founder of Fish in a Barrel), and Josh Aas (co-founder and executive director of the non-profit Internet Security Research Group) chatted about what can be done to reduce memory safety vulnerabilities.
[3]
Memory errors occur when computer code tries to access an area of memory that's undefined, meaning it hasn't been specifically allocated or set aside as part of the heap, stack, or declared data.
[4]
[5]
Memory safety is a complex topic, explored [6]in research papers [PDF] and debated among the technically inclined. But it has the potential to affect anyone who deals with digital technology through bugs in the software or firmware running on electronic devices. It's estimated that [7]at least 65 percent of security vulnerabilities are the result of memory errors .
Memory safety is primarily an issue in programming languages with manual memory management, like C/C++. Improperly managed memory can lead to out of bounds reads and writes and use after free errors. When flaws of this sort can be exploited, attackers may be able to take control of affected devices or steal data. It's enough of a problem to concern the US National Security Agency, which published [8]a paper [PDF] on memory safety last November.
[9]
More modern programming languages that incorporate garbage collection to manage memory – like Java, Python, JavaScript, and Go, among others – help programmers avoid memory-related flaws.
Then there's Rust, a relatively recent programming language, which relies on [10]the concept of ownership to make memory safety guarantees while avoiding the performance cost of automated garbage collection.
The possibility of writing code that's both memory safe and fast has made Rust something of a cause célèbre in certain circles. Last September, Microsoft Azure CTO Mark Russinovich went so far as to suggest that new software projects that might have been started in C/C++ [11]use Rust instead .
[12]
Endorsing Russinovich's mandate, security firm Chainguard on Wednesday [13]said Wolfi , a memory safe Linux "undistro" – designed for producing secure container images – has incorporated the memory safe [14]Rustls TLS library and HTTP via the Rust-based Hyper library in the curl network request tool.
The Internet Security Research Group (ISRG), best known for developing Let's Encrypt, helped bring memory safe TLS and HTTP to Wolfi through a project called [15]Prossimo , which is focused on rewriting critical open source code (e.g. NTP, DNS, TLS) to make it memory safe.
Josh Aas from ISRG told The Register in a phone interview that he believes the conversation around memory safety follows from a confluence of events.
[16]Microsoft applies coat of Rust to Azure Sphere IoT platform
[17]Google polishes Chromium code with a layer of Rust
[18]C++ zooms past Java in programming popularity contest
[19]Linux kernel 6.1: Rusty release could be a game-changer
"I think there's more focus on security than ever and more understanding that memory safety is one of the biggest issues there is," he said. "There's also the recent maturing of tools that help us to address memory safety – the tools we have available to us today are much better than tools we had five years ago and certainly 10 or 20 years ago.
"When it comes to Consumer Reports [exploring the topic]… memory safety may be a somewhat esoteric aspect of software engineering, but the problems caused by a lack of memory safety are so serious that it is a real consumer-level issue."
Aas made it clear that he doesn't believe Rust alone is the answer to memory safety.
"The reason that you hear Rust a lot in this conversation is because Rust gives you memory safety with performance that is comparable to, or better than C," he said. "But if you're not highly performance sensitive in the ways that Rust addresses, then you have lots of choices."
Asked about C++ creator Bjarne Stroustrup's [20]assertion that ISO standard C++ can be memory safe when rules are enforced with static analysis, Aas expressed skepticism.
"In a very theoretical sense that ignores the practicalities of the real world, that might be true," he said. "It might very theoretically be practically possible to write memory safe C++. But it's just not how things work in our world. There are just better ways to do that. C++ was not designed from the ground up to offer memory safety."
In Rust We Trust: Microsoft Azure CTO shuns C and C++ [21]READ MORE
In an ISRG blog post planned for Thursday that was previewed by The Register , Aas offered some advice to software developers and open source maintainers who may be thinking about the transition to memory safe code.
First, he advises that developers stop creating more unsafe code by writing new projects in memory unsafe languages – which is what Microsoft's Russinovich said.
Second, he says, not everything needs to be rewritten at once. Focus first on security-critical modules.
Third, he says, open source maintainers don't necessarily need to learn Rust to help with the memory safety transition because many Rust-based modules come with C APIs.
Finally, he argues that the open source community should understand that the current status quo – an endless parade of memory errors – does not have to continue.
"Three years ago, the conversation was about should we do this," said Aas. "And now I think we're past the 'should' and we're on the 'how'." ®
Get our [22]Tech Resources
[1] https://advocacy.consumerreports.org/research/report-future-of-memory-safety/
[2] https://www.usenix.org/conference/enigma2023/presentation/fireside-chat-memory-safety
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y9Kxq9D6s08-J3y6GuAEkgAAAJg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y9Kxq9D6s08-J3y6GuAEkgAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y9Kxq9D6s08-J3y6GuAEkgAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://arxiv.org/pdf/1705.07354.pdf
[7] https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/
[8] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y9Kxq9D6s08-J3y6GuAEkgAAAJg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html
[11] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y9Kxq9D6s08-J3y6GuAEkgAAAJg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://www.chainguard.dev/unchained/building-the-first-memory-safe-distro-wolfi
[14] https://www.memorysafety.org/initiative/rustls/
[15] https://www.memorysafety.org/
[16] https://www.theregister.com/2023/01/13/microsoft_rust_azure_sphere/
[17] https://www.theregister.com/2023/01/12/google_chromium_rust/
[18] https://www.theregister.com/2022/12/10/java_slips_behind_c_in/
[19] https://www.theregister.com/2022/12/09/linux_kernel_61_column/
[20] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[21] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[22] https://whitepapers.theregister.com/
"many Rust-based modules come with C APIs"
This is clearly the way forward, as it avoids the necessity to fundamentally rethink one's development practice and it also facilitates conversion of existing code.
It's sad that almost nobody ever got their heads round writing memory safe code in C (it can be done - I've done it), but this is probably the next best and more feasible option (provided there are no serious hidden vulnerabilities of other kinds in the rust modules).
Re: "many Rust-based modules come with C APIs"
Well, IMHO, it is a poor design when humans are expected to overcome deficiencies rather than allow the [already existing] automation to do the job more efficiently, every time.
In other words, IMHO, the problem is that the coders are expected to protect memory in C rather than spotting this out, and disallowing it, in the compiler. Of course the problem is legacy - back in the Ye Olden Days, when C was originally created, giving that level of power to the coders was seen as a benefit (just like how much power they gave [unnecessarily] to JS) and compilers weren't powerful enough to do the job, either. But programs back then didn't have to deal with today's hardware and software complexities; there was no predictive branching, memory space was massively limited, multiple cores sharing conjoined structures, etc. C was kept on, unmoved, as programmers loved the power of the available API's but couldn't deal with the increasing inter operational complexities that are possible in today's systems. C+ and C++ was created in hopes of dealing with some of it but not completely.
It needs to be 'intrinsic' in the system, and multi-layers, because humans are [very] fallible. If hardware was perfect (which it will never be), the hardware memory protections would be sufficient. But they aren't, so we need multi-tiered protection.
I personally have believed in Rust since first hearing of it, I can hope that it will really taper down vulnerability attacks that we hear about in the future.
What's life without a little risk?
Risks provide us with drive to do things and when headed teach us valuable lessons. Classic knee-jerk complacency. "Oh no, C and C++ are dangerous 'cos I could make mistakes. Boo hoo!". Holy heck, I could cut my finger off with a bread knife and bleed to death before the week is out, oddly I haven't thrown all the sharp things away yet! I'm not in the least bit interested in C or C++ anymore but I respect that they have a place and like chainsaw, they can be bloody dangerous in the wrong hands but that's life. You pay decent money to a professional then you put faith in their abilities to mitigate such things.
Don't get me wrong, devs need to be efficient and I see solid languages that will aid in helping coders concentrate on logic and squirral away the nasty things that could go wrong but that's the reason being a coder is so well paid, in the wrong location and the wrong code you get nuclear meltdown and rockets going bang. Most of the time an app crashes and some data has to be reloaded.
The curmudgeon in me is desperate for a rant I guess about how the world is too comfortable and risk free, from cradle to grave no one will take risks anymore and we're losing the ability to learn from our mistakes and make ourselves better for it.
Neglecting the legacy?
While it may be beneficial to newer and better(?) tools for new projects, there are legacy systems in place nonetheless. So what about them?
The focus on memory safety should not be wasted in "Rust vs. C++" debates. The energy should go into addressing the causes for memory-unsafe code, and to devise ways to mitigate these.
We do this all the time.
People are inherently selfish, hence we enact rules and guidelines to help us creating a reasonably well functioning society.
Think about your city's traffic, if there weren't any traffic rules.
The rustaceans should do their thing, and the C++ people should strive to achieve memory safety on their part.
And if C++ isn't inherently memory safe, then some framework is needed to ensure that the resulting code is.
However, this does not work well with copy&pasting code from the internets or doing away with testing and Q&A teams.
Hence, I get my coat.
Consumer Reports: Six blind men and an elephant writing a magazine.