[HN Gopher] Eliminating Memory Safety Vulnerabilities at the Source
___________________________________________________________________
Eliminating Memory Safety Vulnerabilities at the Source
Author : coffeeaddict1
Score : 60 points
Date : 2024-09-25 18:49 UTC (4 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| steveklabnik wrote:
| This is a very interesting post! One takeaway is that you don't
| need to re-write the world. Transitioning _new_ development to a
| memory safe language can bring meaningful improvements. This is
| much easier (and cheaper) than needing to port everything over in
| order to get an effect.
| cakoose wrote:
| _What happens if we gradually transition to memory-safe languages
| for new features, while leaving existing code mostly untouched
| except for bug fixes?_
|
| ...
|
| _In the final year of our simulation, despite the growth in
| memory-unsafe code, the number of memory safety vulnerabilities
| drops significantly, a seemingly counterintuitive result [...]_
|
| Why would this be counterintuitive? If you're only touching the
| memory-unsafe code to fix bugs, it seems obviously that the
| number of memory-safety bugs will go down.
|
| Am I missing something?
| cogman10 wrote:
| The counter intuitive part is that there is now more code
| written in memory unsafe languages than there was before. Even
| if it's just bug fixing.
|
| It's not as if bug fixes haven't resulted in new memory bugs,
| but apparently that rate is much lower in bug fixes than it is
| in brand new code.
| Animats wrote:
| Half a century since Pascal. Forty years since Ada. 28 years
| since Java. Fifteen years since Go. Ten years since Rust. And
| still unsafe code is in the majority.
| mpweiher wrote:
| Well, that tells us something...
| tiffanyh wrote:
| Doesn't libc interface requirement of C/C++ use, create massive
| downstream challenges for other languages to gain super mass
| adoption (at the OS level).
| sanxiyn wrote:
| Yes, but Linux (hence Android) doesn't have that problem,
| because its interface is system call not libc.
| SkyMarshal wrote:
| They talk about "memory safe languages (MSL)" plural, as if there
| is more than one, but only explicitly name Rust as the MSL
| they're transitioning to and improving interoperability with.
| They also mention Kotlin in the context of improving Rust<>Kotlin
| interop, which also has some memory-safe features but maybe not
| to same extent as Rust. Are those the only two Google uses, or
| are there others they could be referring to?
| steveklabnik wrote:
| A few thoughts:
|
| People who care about this issue, especially in the last few
| years, have been leaning into a "memory safe language" vs "non
| memory safe language" framing. This is because it gets at the
| root of the issue, which is safe by default vs not safe by
| default. It tries to avoid pointing fingers at, or giving
| recommendations for, particular languages, by instead putting
| the focus on the root cause.
|
| In the specific case of Android, the subject of this post, I'm
| not aware of attempts to move into other MSLs than those. But I
| also don't follow Android development generally, but I _do_
| follow these posts pretty closely, and I don 't remember any of
| them talking about stuff other than Rust or Kotlin.
| alpire wrote:
| Android talked more about the memory-safe languages they're
| using in a previous blog post:
| https://security.googleblog.com/2022/12/memory-safe-language...
|
| Google also published their perspective on memory safety in
| https://security.googleblog.com/2024/03/secure-by-design-
| goo..., which also goes over some of the memory-safe languages
| in use like Java, Go and Rust.
| dgacmu wrote:
| There are many and google uses several - rust, python, java,
| and go among them. But low-level code for Android has
| historically been in c++ and Rust is the primary memory-safe
| replacement for the stuff they're building.
| jnwatson wrote:
| Java and Kotlin are used for apps. Rust is used for new system
| software.
|
| Across Google, Go is used for some system software, but I
| haven't seen it used in Android.
| nightpool wrote:
| It's not just Rust--rewriting a C network service into Java or
| Python or Go is also an example of transitioning to memory safe
| languages. The point is that you're not exposed to memory
| safety bugs in your own code. Arguably it's much better to
| choose a language _without_ Rust-like manual memory management
| when you don 't absolutely need it.
| daft_pink wrote:
| I'm curious how this applies to Mac vs Windows, where most newer
| Mac code is written in memory safe swift, while Windows still
| uses primarily uses C or C++.
| akyuu wrote:
| Apple is still adding large amounts of new Objective-C code in
| each new macOS version [0].
|
| I haven't found any language usage numbers for recent versions
| of Windows, but Microsoft is using Rust for both new
| development and rewriting old features [1] [2].
|
| [0] Refer to section "Evolution of the programming languages"
| https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
|
| [1]
| https://www.theregister.com/2023/04/27/microsoft_windows_rus...
|
| [2]
| https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...
| munificent wrote:
| _> while Windows still uses primarily uses C or C++._
|
| Do you have data for that? My impression is that a large
| fraction of Windows development is C# these days. Back when I
| was at EA, nearly fifteen years ago, we were already leaning
| very heavily towards C# for internal tools.
| tsujamin wrote:
| Linking to my thread from yesterday, there's definitely
| memory safe systems programming happening over there:
| https://news.ycombinator.com/item?id=41642788
| ievans wrote:
| So the argument is because the vulnerability lifetime is
| exponentially distributed, focusing on secure defaults like
| memory safety in _new code_ is disproportionately valuable, both
| theoretically and now evidentially seen over six years on the
| Android codebase.
|
| Amazing, I've never seen this argument used to support shift/left
| secure guardrails but it's great. Especially for those with
| larger, legacy codebases who might otherwise say "why bother,
| we're never going to benefit from memory-safety on our 100M lines
| of C++."
|
| I think it also implies any lightweight vulnerability detection
| has disproportionate benefit -- even if it was to only look at
| new code & dependencies vs the backlog.
| xyst wrote:
| Infosec folks hate this.
___________________________________________________________________
(page generated 2024-09-25 23:00 UTC)