Well what a surprise! Any C or C++ programmer will tell you that mismanaging memory is the biggest problem that they have. But 70% of all security problems down to memory - that might be more than expected.

One of the great attractions of C/C++ is the ability to work with memory at a very low level. Of course, this is also their disadvantage. It is too easy to make a mistake. The most common error is "use-after-free". This occurs when you try to use a pointer to memory after the memory has been freed. Sometimes it works because the system hasn't destroyed or reallocated the memory and so your program gets a sort of free ride. Then, some time in the future, the system does get round to deallocating, and even reusing, the memory and the results are unpredictable.

This is such a well-known problem that most C/C++ programmers are careful not to make the mistake and yet the Chromium team claims that 36% of all of the security problems that they identified are "use-after-free". It is an error so simple to spot that you'd think we could avoid it, but it is also simple to make. Freeing memory happens at one place in a program and using it happens in another. The two places are often separated in time as well as loc and the result is a dangling pointer somewhere lost in space.

The analysis recently performed by the Chromium security team looks at problems found in the code from 2015. Unfortunately the rest of the analysis isn't so informative. The remaining memory problems are just called "Other memory unsafety", which account for around a third of the total, but you can bet that includes pointer overruns. There there are the catch-all uninformative categories of "Other" and "Security-related assert" with shares of 24% and 7% respectively.

The 70% figure aggrees with an earlier finding by Microsoft: Memory Safety Bugs Form 70 Percent Of Vulnerabilities

The post also includes the statement:

"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. Over the past years that architecture has been enhanced to ensure that websites are isolated from one another. That huge effort has allowed us — just — to stay ahead of the attackers. But we are reaching the limits of sandboxing and site isolation."

What is the solution? The post suggests that three ideas might be helpful. The first is to use custom libraries that are designed to be safe. The second is to use custom dialects of C++ and perhaps ban raw pointers from C++ code altogether, include bounds checks an use a garbage collector. The third is perhaps the most interesting  because it proposes using safer languages. You might be surprised at the suggested languages:

• Java and Kotlin
• JavaScript
• Rust
• Swift
• ...

Well, of that set, I've never thought of Java, Kotlin, JavaScript or Swift as being particularly safe. However, given the way that they manage memory they are safer than C++. Even so memory leaks are common in all of them.

Then there is Rust - the language we currently seem to invest so much hope in. Could it be that Rust with is concepts of ownership is the long-term solution? If so, it probably is long term because it would be a brave Chromium developer who committed to the language at this still early stage. Let others, Microsoft and Mozilla, experiment and see where it goes.

In the meantime we just have to put up with the inevitable security bugs that manual memory management seems to entail. Surely there has to be a better way?

More Information

https://www.chromium.org/Home/chromium-security/memory-safety

Related Articles

Counting Vulnerabilities In Open Source Projects and Programming Languages

Memory Safety Bugs Form 70 Percent Of Vulnerabilities

Is Rust Really Safe?

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info