Google says 70 percent of serious security bugs in Chrome are memory safety issues

[Shawn Knight]

In brief: The majority of serious security bugs in Chrome are due to memory safety issues. Google engineers came to that conclusion after analyzing 912 high or critical severity bugs affecting stable channel releases since 2015.

Google notes in this memory safety report that Chromium’s security architecture was designed to assume that such bugs exist, using sandboxes to help stop them from taking over host machines. It’s an effort that has allowed the team to stay ahead of attackers, but just barely. Worse yet, they’re reaching the limits of what is possible with sandboxing and site isolation.

It’s an issue that isn’t limited to Google, either. Most vulnerabilities found in iOS and macOS are also caused by memory unsafety. Microsoft said last summer that 70 percent of the security vulnerabilities it fixes and assigns a CVE (Common Vulnerabilities and Exposures) number are due to memory safety issues. And according to this analysis, more than 80 percent of zero-day vulnerabilities are due to memory problems.

With stronger sandboxing no longer advantageous and deploying additional processes off the table, Google said it must attack memory unsafety problems by “any and all means necessary.” This includes exploring custom C++ libraries and utilizing safer languages like JavaScript, Rush and Swift when applicable.

Permalink to story.

https://www.techspot.com/news/85368-google-70-percent-serious-security-bugs-memory-safety.html

 

[redhat]

Spelling mistake: Rush >> Rust;
cout << C++ out;

 

[Plutoisaplanet]

Spelling mistake: Rush >> Rust;
cout << C++ out;

Lmao that’s perfect, I love it

 

[ChickyBoom]

"Google says 70 percent of serious security bugs are memory safety issues" -- I think they meant to say "are due to bad programming practices." ha!

 

[quadibloc]

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.

 

[Uncle Al]

Let's face it .... today's programmers have become lazy and follow no set standard for testing and verification. If they had to face the requirements that existed in the 1990's we wouldn't see near this many issues .....

 

[DadDanko]

I know it is archaic but back when I worked with Burroughs mainframes the OS was compiled such that anything executable was hardware read only.