Remember when hackers didn’t target Web browsers? Remember when Internet-connected client code didn’t need to be hardened against “untrustworthy inputs”?
That was a long time ago—decades in fact. So surely we’ve licked the problem by now, right? Umm, about that …
Google’s tried to fix it with sandboxing, but progress has been stymied by performance issues. So now the Chromium team is considering memory-safe languages, such as Rust. In this week’s Security Blogwatch, we gently scoff at trendy magic beans.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: He gives in and embeds Cheap Cuts.
Beware baby+bathwater bogosity
What’s the craic? Catalin Cimpanu reports—Chrome: 70% of all security bugs are memory safety issues:
Half of the 70% are use-after-free vulnerabilities … leaving doors open for attackers to attack Chrome's inner components. … Engineers analyzed 912 security bugs fixed in the Chrome stable branch since 2015, bugs that had a "high" or "critical" severity rating.
…
The number is identical to stats shared by Microsoft … in February 2019. … Both companies are basically dealing with the same problem: … C and C++ … are "unsafe" languages … created decades ago when security exploitation and cyber-attacks were not a relevant threat model.
…
Vulnerabilities like use-after-free, buffer overflow, race conditions, double free [and] wild pointers … are the most sought-after bugs that attackers try to find and exploit, as they can grant them the ability to plant code inside a device's memory and have it executed.
…
Google … plans to look into "tackling the memory unsafety problem" for Chrome, today's most popular web browser. … Google engineers say that their approach to sandboxing Chrome's components has reached its maximum benefits when taking performance into account.
And Gordon Kelly adds—Google Just Gave Millions Of Users A Reason To Quit Chrome:
This is a big deal. Memory management flaws are the most highly prized vulnerability by hackers, coming first, fifth and seventh in the top 10 list of dangerous vulnerabilities by Mitre. … But it doesn’t have to be this way.
While all Chromium-based browsers (Microsoft Edge, Opera, Brave, etc) are … subject to the same weaknesses, one alternative stands out: Firefox. Unlike Chromium browsers, Firefox is built using Rust, a safety-focused programming language which is specifically designed to be memory safe.
…
Now Google states it is looking at Rust, along with Swift, JavaScript, Kotlin and Java as programming languages to replace the C and C++ code in Chrome. … It is to Google’s credit … but there is no timeline on how long this will take.
…
In the meantime … Firefox looks like a good bet.
Use the source, puke. The anonymous Chromium security team talk Memory safety:
Our next major project is to prevent … memory safety … bugs at source. … These bugs are spread evenly across our codebase, and a high proportion of our non-security stability bugs share the same types of root cause. As well as risking our users’ security, these bugs have real costs in how we fix and ship Chrome.
…
Chromium’s security architecture has always been designed to assume that these bugs exist, and code is sandboxed to stop them taking over the host machine. … But we are reaching the limits of sandboxing and site isolation. A key limitation is that the process is the smallest unit of isolation, but processes are not cheap—especially on Android.
…
Staying still is not an option. … Attackers innovate, so defenders need to innovate just to keep pace. … We’re tackling the memory unsafety problem … by any and all means necessary. … We expect this strategy will boil down to two major strands:
- Significant changes to the C++ developer experience, with some performance impact. …
- An option of a programming language designed for compile-time safety checks with less runtime performance impact.
But shouldn’t we blame the programmers, rather than the programming language? technovelist puns it up:
It's entirely possible to write C++ programs that don't have these problems, but you have to know what you are doing. I know because I do it all the time. I can't recall the last time I had memory issues. :-)
…
[But] you can write bad programs in C++, as you can in any language that gives you enough control to get peak performance. The problem is not the language. It's that most programmers aren't very good.
Similarly, johannesg points to more fundamental practices:
They are still using naked new/delete pairs. C++ has considered that to be a bad practice since at least C++11 … preferring to use std::unique_ptr and std::shared_ptr instead. Doing so completely automates the effort of freeing memory, so you cannot forget to free, nor have double frees.
It's easy to ask for a rewrite in another language that is nominally safer, but it's probably much cheaper to finally start using basic best practices.
And get off my lawn. quadibloc yearns for the Good Old Days:
One reason why so many programmers make mistakes, leaving programs vulnerable to buffer overflows, is that buffer overflows are not an issue on some computers where many people learned to program. An IBM System/360 mainframe usually handles end-of-record in an out-of-band manner, so that there's no possibility of reading a record going past the end of a buffer – records aren't delimited by characters like line feed, carriage return, or nulls, but instead they behave like Pascal strings.
It's too bad it would be too hard to change Windows or even Linux to make them like that.
But Anthony Cowley—@a_cowley—facepalms thuswise:
I’m seeing reactions that Google should have hired real Software Engineers.
…
It’s really striking how much more ambitious Mozilla has been with addressing the problem. Kudos to them.
Get off my lawn (again) is the response from the self-styled OneSmartFellow, who diverts from the focus on language:
C++ has had totally adequate "memory safety" since the adoption of boost shared pointers. … A big part of memory safety lies in … address randomization and other features [which] are just as important.
But, but, Rust! … It's the flavor of the month! So, it must be better, even if it's decades less mature.
Yawn.
Meanwhile, LockAndLol foreshadows the inevitable pushback from Rust haters:
I can already hear the pop from the aneurysms the anti-memory managed crowd will be getting.
The moral of the story?
If you’re writing C++ code, use best practices to manage memory. If you’re using or considering a language such as Rust, don’t treat it as a magic panacea that cures all ills.
And finally
Trigger warnings: Marijuana use; low battery; existential ennui.
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Image source: Chromium Project (BSD)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
