As Microsoft last year, the Chromium project team, responsible for the Chromium browser (which is the base of many open source and proprietary projects like Chrome, Brave, or Visual Studio Code), released a blog post last week about memory bugs in Chromium.

The analysis

The analysis has been based on both past and present 912 high or critical severity security issues, since 2015.
Based on those bugs, the observation is clear:

The Chromium project finds that around 70% of our serious security bugs are memory safety problems.
[…] Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.

Despite the efforts of the project team to maintain good security architecture in managing sandboxing and site isolation, to let those heavy components manage and contain the severity of memory bugs has both limitations and resources cost.
Also, even if those security components (or layers) stay necessary for daily usage, this not enough to stop attackers and avoid attacks.

Instead, as stated in the blog post:

[…]The cheapest way to maintain the advantage is to squash bugs at source instead of trying to contain them later.

The different solutions

As always in software projects, solutions (and decisions) come with a trade-off.
Indeed, the team developed a plan to solve those issues, using two criterias:

• time and resources costs needed to implement the improvement(s),
• the real benefit of those costs, basically the number and the quality of those improvement(s).

This spectrum reflects the different strategies offered by the team, from left to right:

1. to keep their dev model in unsafe system programming languages (like C or C++) but to bring attention on memory safety first (spatial memory safety, custom C++ libraries, and moving to newer standards like C++17 or the next C++20);
2. customize their needs using custom C++ dialects, and / or continue on their idea of using a C++ garbage collection library for Chromium;
3. move to a safe system programming language (and ecosystem) like Swift or Rust, to bind with C++ parts first before rewriting those.

This plan is not new, as the Mozilla foundation already made experiments about switching from C++ to Rust since 2015).
Indeed, to make the switch to another technology has a big cost in a project, because it implies both to limit new upcoming features and to give some time to developers to embrace a new technology that they may not be accustomed to use daily. Also, the plan here is to have a long-term vision, and not switching again to another technology in five or ten years.

In my opinion, to switch first to “modern C++” can be a good option for a short term solution, but is may not be a great option to “save your ass” all the time.
Rust of Swift are definitely game changers in tech since their first stable version release.

To go further

• An excellent blog post from Mozilla about preventing developers about memory safety and memory bugs: link to blog article.
• My article about security by design, in the Tadaweb blog: link to blog article