The push towards memory safe programming languages is strong, and for good reason. However, especially for bigger projects with a lot of code that potentially needs to be rewritten or replaced, you might question if all the effort is even worth it, particularly if all the main contributors would also need to be retrained. Well, it turns out that merely just focusing on writing new code in a memory safe language will drastically reduce the number of memory safety issues in a project as a whole.
Memory safety vulnerabilities remain a pervasive threat to software security. At Google, we believe the path to eliminating this class of vulnerabilities at scale and building high-assurance software lies in Safe Coding, a secure-by-design approach that prioritizes transitioning to memory-safe languages.
This post demonstrates why focusing on Safe Coding for new code quickly and counterintuitively reduces the overall security risk of a codebase, finally breaking through the stubbornly high plateau of memory safety vulnerabilities and starting an exponential decline, all while being scalable and cost-effective.
↫ Jeff Vander Stoep and Alex Rebert at the Google Security Blog
In this blog post, Google highlights that even if you only write new code in a memory-safe language, while only applying bug fixes to old code, the number of memory safety issues will decreases rapidly, even when the total amount of code written in unsafe languages increases. This is because vulnerabilities decay exponentially – in other words, the older the code, the fewer vulnerabilities it’ll have.
In Android, for instance, using this approach, the percentage of memory safety vulnerabilities dropped from 76% to 24% over 6 years, which is a great result and something quite tangible.
Despite the majority of code still being unsafe (but, crucially, getting progressively older), we’re seeing a large and continued decline in memory safety vulnerabilities. The results align with what we simulated above, and are even better, potentially as a result of our parallel efforts to improve the safety of our memory unsafe code. We first reported this decline in 2022, and we continue to see the total number of memory safety vulnerabilities dropping.
↫ Jeff Vander Stoep and Alex Rebert at the Google Security Blog
What this shows is that a large project, like, say, the Linux kernel, for no particular reason whatsoever, doesn’t need to replace all of its code with, say, Rust, again, for no particular reason whatsoever, to reap the benefits of a modern, memory-safe language. Even by focusing on memory-safe languages only for new code, you will still exponentially reduce the number of memory safety vulnerabilities. This is not a new discovery, as it’s something observed and confirmed many times before, and it makes intuitive sense, too; older code has had more time to mature.
IF
require-memory-safety
AND
require-lower-cognitive-load-than-C++
THEN
Use Modula-3 programming language.
E.g. https://github.com/modula3/cm3/discussions/1177
END (* IF *) ;
Yeah, I was about to say Pascal, but Modula-2 or 3 will do.
Otherwise, ADA or LISP.
BASIC in 2024 has Potential : https://www.youtube.com/watch?v=7_EV22SpDY4&t=1h01m40s
There is quite a bit of self-fulfilling prophecy to this.
If you are talking about and implementing memory safety, you are more likely to look for and spot where it isn’t. And therefore to fix it.
I’ve had similar in roles where I shifted the teams focus to secure implementation by design, once that practice took hold, everywhere they looked in the old code were holes they’d ignored or accepted for years. So the team themselves were pushing neglected areas up the priority list
I think this is true. However, using memory safe languages within the same code base helps ensure that you are ACTUALLY taking it seriously and not just talking about it. Look at the recent dust-up with the Linux kernel maintainers. A lot of what the Rust guys were asking for was just to know the proper semantics of the C code and to ensure that new structures were created in a way that at least was compatible with a memory safe language. If you cannot commit to those two things in your C code, there is a good chance you are not focusing on memory safety.
tanishaj,
Yes, that’s the thing. I do get the annoyance of having to declare intentions in a safe language, but this is something C coders should be doing mentally anyway. A safe language just makes that explicit. Knowing that object lifespan is valid is immensely beneficial especially in team settings where it’s easy to miss an assumption.
Adurbe,
I can vouch for this too 🙂
Sometimes prototypes that aren’t thoroughly debugged become production code. Other times there’s just no time/resources to fix it. Devs do the best they can with what they have but not having enough developers/money to fix it is very common for both FOSS as well as commercial software.Sometimes devs get blamed for the mistakes, but people need to understand that the sheer scope of work and rush to get things done becomes overwhelming. I work on teams where the backlog of issues is so great there’s zero possibility of getting through them and they have to be prioritized.
That said, I don’t think just having more eyes is sufficient, we also need safer tools & languages to reduce human errors and enforce correct memory management. We’ll still have bugs, but being able to automatically catch the worst threading/memory corruption bugs is a big benefit.
I can Very much relate to the commercial pressures compromising quality, I think our backlogs easily number in the thousands. And I Totally agree that tools form part of the solution. Even a half decent static scanner would pick up the worst errors. Making it easy is always the first and biggest barrier!
MorphOS does not have protected memory and i have not had a crash in almost two years of the system. Something else is at play.
I think there are two things going on here.
First, as has been said, code which has been around longer is less likely to present memory safety bugs. It may have had them in the past but many will have been found and dealt with. Using a memory safe language for new code means fewer memory safety issues in new code and therefore fewer issues in the code overall even if most of the code is in a non-memory safe language. Sure.
However, I think another factor is that, where the old and new code meet, you have to create interfaces that can be used from the memory safe language. Sometimes, that is going to impose constraints on the non-memory safe code. That is going to piss the old guys off but it is also going to result in a design that better promotes memory safety.
If this is correct, it means that there will be fewer memory safety issues in new code even when that code continues to be written in a non-memory safe language. That is a real benefit in a giant code base like Linux ( for example ).
So reading the report they acknowledge majority of code still is on what they call “unsafe code”. On top of that they seem to accept that now and will rather focus in providing better interoperability. That is for Rust to work better with C++ and Kotlin, beyond that they are providing some rather sparse founding to bring Rust to GNU/Linux. Considering the hype i didn’t expect such peanuts.
In general I agree with the approach with a few modifications. There are older sections of code that haven’t really been probed by anyone but are highly sensitive. OpenSSL was this way for a long long time. I think those could be/should be prioritized for replacement with a memory secure language. Assuming that there is great test coverage, and the developers are competent. Ie, don’t re do something like OpenSSL in rust with kids straight from college, it won’t end well.
Bill Shooter of Bul,
I was a bigger fan of openssl until I actually had to incorporate it into another code base, haha. That code is really messy in there and I actually think it would be a good candidate for clean up. I’ve been using bouncycastle in c# and I’ve found it much better to work with.
https://www.bouncycastle.org/about/
Of course it’s written for managed languages, so there’s that difference. And of course I must agree with your point about the importance of experience when it comes to crypto libraries. Rust crypto could be very valuable, but it needs to be overseen by someone with the appropriate experience.
I also found OpenSSL lacking. Have a look at https://github.com/Kochise/Crypto (fork) even if it’s a bit old.
You’ve got a lot of projects on there, awesome stuff!
You’re a big Atari fan, haha. It’s always interesting to learn about others. I haven’t uploaded most of my personal projects, I never expect anyone else to care about them.
Yeah, that’s my pet projects that could interest anyone into retro. I’m touching pretty much everything but web stuff though.