Google's memory safety plan includes rehab for unsafe languages
(2024/10/16)
- Reference: 1729059794
- News link: https://www.theregister.co.uk/2024/10/16/google_legacy_code/
- Source link:
Google has revealed that its approach to making programming code more memory safe involves both the adoption of memory safe languages and making unsafe languages more secure – to the extent that's possible.
The Chocolate Factory has been an avid booster of memory safety for the past few years – [1]celebrating the security benefits that accrue when code is written or rewritten in a language that, like Rust, offers guarantees of memory safety.
But the biz also acknowledges that legacy C and C++ code can't all be revised or discarded. So it's trying to balance its memory safety evangelism with the reality that C and C++ codebases will exist for decades to come, and they must be hardened.
[2]
This two-pronged approach has been discussed for some time, but the part about learning to live with unsafe code often gets drowned out by the appreciative odes to Rust and other memory safe languages (MSLs) like Java, Kotlin, Go, and Python.
[3]
[4]
"Our long-term objective is to progressively and consistently integrate memory-safe languages into Google's codebases while phasing out memory-unsafe code in new development," explained Googlers Alex Rebert, Chandler Carruth, Jen Engel, and Andy Qin in a [5]blog post . "Given the amount of C++ code we use, we anticipate a residual amount of mature and stable memory-unsafe code will remain for the foreseeable future."
Memory safety bugs date back more than 50 years and occur when code tries to read or write memory in a way that's undefined – a concern that Rust contributor Steve Klabnik [6]argues goes beyond memory safety. Undefined behaviour may occur, for example, when a program in an unsafe language tries to access an object's memory outside of its allocated memory region. The result is an out of bounds error.
[7]
Other memory safety flaws arise when, for example, a pointer references heap-allocated memory that has been freed.
Such issues turn out to be rather common in C and C++, which make programmers responsible for memory management.
Which may be why 75 percent of the CVEs used in zero-day exploits are memory safety vulnerabilities, [8]according to Google . About 70 percent of severe vulnerabilities in large codebases are attributable to such bugs.
[9]
The repeated citation of such statistics over the past few years has led to an international campaign – backed by government cyber security agencies – to use MSLs where possible, as well as initiatives to convert existing unsafe code [10]into something more sound .
[11]DARPA pays $6M to see fully autonomous Black Hawk helicopters
[12]Digital River runs dry, hasn't paid developers for sales since July
[13]Google hopes to spark chain reaction with nuclear energy investment
[14]Anthropic's Claude vulnerable to 'emotional manipulation'
Google [15]has embraced MSLs and tried to harden C++. "We have allocated a portion of our computing resources specifically to [16]bounds-checking the C++ standard library across our workloads," explained Rebert et al , adding that the promising results of this effort will be shared at a later date.
In addition to Chrome's [17]MiraclePtr mechanism , which has cut use-after-free memory bugs by more by 57 percent, Google's ongoing efforts to expand isolation techniques like sandboxing and privilege reduction have led to projects like the beta release of the [18]V8 heap sandbox , an LLM-based vulnerability hunting tool called [19]Project Naptime , support for Arm's [20]Memory Tagging Extension (MTE), and research into [21]Capability Hardware Enhanced RISC Instructions (CHERI) architecture.
Google is not alone in its work to fortify C and C++. The Open Source Security Foundation has published [22]a guide to hardening C and C++ code . The C++ Alliance recently published a [23]Safe C++ Extensions proposal . C23 – a draft of the latest version of the C programming language – has features like [24]N3020 , Qualifier-preserving Standard Functions, which help improve read-only memory safety.
Also, Bjarne Stroustrup, creator of C++, has proposed [25]Safety Profiles [PDF] – a set of rules that makes certain safety guarantees.
Memory safe languages may be the future – but for some time to come, so are C and C++. ®
Get our [26]Tech Resources
[1] https://www.theregister.com/2024/09/25/google_rust_safe_code_android/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html
[6] https://steveklabnik.com/writing/memory-safety-is-a-red-herring/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://googleprojectzero.blogspot.com/p/0day.html
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2024/08/03/darpa_c_to_rust/
[11] https://www.theregister.com/2024/10/15/black_hawk_autonomous_tech/
[12] https://www.theregister.com/2024/10/15/digital_river_runs_dry_hasnt/
[13] https://www.theregister.com/2024/10/15/google_kairos_smr_nuclear_investment/
[14] https://www.theregister.com/2024/10/12/anthropics_claude_vulnerable_to_emotional/
[15] https://www.theregister.com/2024/09/25/google_rust_safe_code_android/
[16] https://libcxx.llvm.org/Hardening.html
[17] https://www.theregister.com/2024/08/29/google_chrome_vuln_rewards/
[18] https://v8.dev/blog/sandbox
[19] https://googleprojectzero.blogspot.com/2024/06/project-naptime.html
[20] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/enhancing-memory-safety
[21] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[22] https://openssf.org/blog/2023/11/29/strengthening-the-fort-openssf-releases-compiler-options-hardening-guide-for-c-and-c/
[23] https://safecpp.org/P3390R0.html
[24] https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3020---qualifier-preserving-standard-functions
[25] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2816r0.pdf
[26] https://whitepapers.theregister.com/
The Chocolate Factory has been an avid booster of memory safety for the past few years – [1]celebrating the security benefits that accrue when code is written or rewritten in a language that, like Rust, offers guarantees of memory safety.
But the biz also acknowledges that legacy C and C++ code can't all be revised or discarded. So it's trying to balance its memory safety evangelism with the reality that C and C++ codebases will exist for decades to come, and they must be hardened.
[2]
This two-pronged approach has been discussed for some time, but the part about learning to live with unsafe code often gets drowned out by the appreciative odes to Rust and other memory safe languages (MSLs) like Java, Kotlin, Go, and Python.
[3]
[4]
"Our long-term objective is to progressively and consistently integrate memory-safe languages into Google's codebases while phasing out memory-unsafe code in new development," explained Googlers Alex Rebert, Chandler Carruth, Jen Engel, and Andy Qin in a [5]blog post . "Given the amount of C++ code we use, we anticipate a residual amount of mature and stable memory-unsafe code will remain for the foreseeable future."
Memory safety bugs date back more than 50 years and occur when code tries to read or write memory in a way that's undefined – a concern that Rust contributor Steve Klabnik [6]argues goes beyond memory safety. Undefined behaviour may occur, for example, when a program in an unsafe language tries to access an object's memory outside of its allocated memory region. The result is an out of bounds error.
[7]
Other memory safety flaws arise when, for example, a pointer references heap-allocated memory that has been freed.
Such issues turn out to be rather common in C and C++, which make programmers responsible for memory management.
Which may be why 75 percent of the CVEs used in zero-day exploits are memory safety vulnerabilities, [8]according to Google . About 70 percent of severe vulnerabilities in large codebases are attributable to such bugs.
[9]
The repeated citation of such statistics over the past few years has led to an international campaign – backed by government cyber security agencies – to use MSLs where possible, as well as initiatives to convert existing unsafe code [10]into something more sound .
[11]DARPA pays $6M to see fully autonomous Black Hawk helicopters
[12]Digital River runs dry, hasn't paid developers for sales since July
[13]Google hopes to spark chain reaction with nuclear energy investment
[14]Anthropic's Claude vulnerable to 'emotional manipulation'
Google [15]has embraced MSLs and tried to harden C++. "We have allocated a portion of our computing resources specifically to [16]bounds-checking the C++ standard library across our workloads," explained Rebert et al , adding that the promising results of this effort will be shared at a later date.
In addition to Chrome's [17]MiraclePtr mechanism , which has cut use-after-free memory bugs by more by 57 percent, Google's ongoing efforts to expand isolation techniques like sandboxing and privilege reduction have led to projects like the beta release of the [18]V8 heap sandbox , an LLM-based vulnerability hunting tool called [19]Project Naptime , support for Arm's [20]Memory Tagging Extension (MTE), and research into [21]Capability Hardware Enhanced RISC Instructions (CHERI) architecture.
Google is not alone in its work to fortify C and C++. The Open Source Security Foundation has published [22]a guide to hardening C and C++ code . The C++ Alliance recently published a [23]Safe C++ Extensions proposal . C23 – a draft of the latest version of the C programming language – has features like [24]N3020 , Qualifier-preserving Standard Functions, which help improve read-only memory safety.
Also, Bjarne Stroustrup, creator of C++, has proposed [25]Safety Profiles [PDF] – a set of rules that makes certain safety guarantees.
Memory safe languages may be the future – but for some time to come, so are C and C++. ®
Get our [26]Tech Resources
[1] https://www.theregister.com/2024/09/25/google_rust_safe_code_android/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html
[6] https://steveklabnik.com/writing/memory-safety-is-a-red-herring/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://googleprojectzero.blogspot.com/p/0day.html
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_specialfeatures/cybersecuritymonth&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw-OxCqfLBQIO550D_8O0gAAAQE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2024/08/03/darpa_c_to_rust/
[11] https://www.theregister.com/2024/10/15/black_hawk_autonomous_tech/
[12] https://www.theregister.com/2024/10/15/digital_river_runs_dry_hasnt/
[13] https://www.theregister.com/2024/10/15/google_kairos_smr_nuclear_investment/
[14] https://www.theregister.com/2024/10/12/anthropics_claude_vulnerable_to_emotional/
[15] https://www.theregister.com/2024/09/25/google_rust_safe_code_android/
[16] https://libcxx.llvm.org/Hardening.html
[17] https://www.theregister.com/2024/08/29/google_chrome_vuln_rewards/
[18] https://v8.dev/blog/sandbox
[19] https://googleprojectzero.blogspot.com/2024/06/project-naptime.html
[20] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/enhancing-memory-safety
[21] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[22] https://openssf.org/blog/2023/11/29/strengthening-the-fort-openssf-releases-compiler-options-hardening-guide-for-c-and-c/
[23] https://safecpp.org/P3390R0.html
[24] https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3020---qualifier-preserving-standard-functions
[25] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2816r0.pdf
[26] https://whitepapers.theregister.com/
munnoch
I don't think its overnight. That rhetoric has been around for some time now.
Levels of proficiency vary enormously. I've worked with many so-called C++ developers who think a character string is a fine way to represent domain data.
Dan 55
So why were they allowed to use C strings in the first place? No code review caught that out? That could even be automated by getting svn and git to refuse commits which contain "char *".
Back to Google, did management enforce use of RAII, ban use of known unsafe language features, allow time for refactoring old code to use newer C++ features, and improve the toolchain? I suspect they didn't because they admitted as much ("Given the amount of C++ code we use, we anticipate a residual amount of mature and stable memory-unsafe code will remain for the foreseeable future"). If they chose not to follow best practices then decide that's a reason for Rusting all the things, they're going to be surprised when they find there are still problems in their Rust code but I won't be as no technical solution on Earth will fix their problem - they have a management and cultural problem.
"Google, did management enforce use of RAII"
Bebu
Manglement anywhere aren't exactly noted for their technical excellence, or even competence - technical or otherwise.
Suggesting to google management that enforcing the use of RAII might only elicit uniform vacant looks with perhaps the unlikely but definitely odd genius wondering how using a papyrus boat might help.
Crap programmers make C/C++ unsafe
may_i
There's nothing wrong with the languages, only with the developers who are so crap at using them they have no idea how to manage memory allocation and re-use properly.
Please stop
G40
Conflating C with C++ again. Google should know better as well.
Architecture
adam 40
The "problem" isn't C, it's the machine architecture.
Fix that first.
If you have built a long career and a high level of proficiency with C/C++, it must cause a little bit of indignation to suddenly find your work has gained the status of "unsafe" overnight.