Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

351–360 of 606 posts

Re: Memory Safe Languages in Android 13

#351

Post by ShredKazoo »

raggi wrote: post #349
harry8 wrote: post #225

Earlier quoted context omitted.

Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…

WireGuard is a recent and prominent example of a system that has been formally verified ( https://www.wireguard.com/formal-verification/ ). There are implementations in a variety of languages due to integration considerations. You will find at the bottom of that page C implementations of curve25519 that are proofed and derived from F* and Coq. Curve25519 is a relatively simple implementation and only one part of any…

Out of curiosity did the Wireguard formal verification effort end up identifying any security issues in the implementation?

Re: Memory Safe Languages in Android 13

#352

Post by logicchains »

Gigachad wrote: post #282
gnull wrote: post #207

Earlier quoted context omitted.

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle This says more about those C++ defenders.

C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…

>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code.

Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.

Re: Memory Safe Languages in Android 13

#353

Post by codedokode »

robot_no_421 wrote: post #118
codedokode wrote: post #32

Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.

If you want to check for overflow, then you can use the methods that explicitly check for overflow: https://doc.rust-lang.org/std/primitive.u32.html#method.chec... So this is not an issue at all.

They are long to type and hard to read. They are so inconvenient to use that nobody uses them, even developers of Rust. Take source code of Vec as an example [1]. They use wrapping addition instead of checked one.

For comparison, in Swift normal arithmetic operations check for overflow.

[1] https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1773

Re: Memory Safe Languages in Android 13

#354

Post by netr0ute »

nneonneo wrote: post #331
netr0ute wrote: post #269

Earlier quoted context omitted.

> Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs. Are constructions like these really the root cause of CVEs? As long as you do a correct check, then you're all good. If Rust can do the same thing in fewer lines, then that may or may not be a…

Oh absolutely! Here’s an example from 2019: https://www.cve.org/CVERecord?id=CVE-2019-15900 “An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of repor…

The problem here is that that implementation was written in plain old C and is super unsafe, and is NOT C++. I don't know why C keeps getting confused with C++ because the two are basically totally different now.

Re: Memory Safe Languages in Android 13

#355

Post by logicchains »

Ar-Curunir wrote: post #255
ghostwriter wrote: post #238

Earlier quoted context omitted.

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about exis…

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

>If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.

Re: Memory Safe Languages in Android 13

#356

Post by p-e-w »

yosefk wrote: post #199
lolinder wrote: post #116

Their notes about vulnerability severity are particularly interesting. Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle of switching to a new language. Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages…

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages

Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half.

For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice.

And now imagine, in reaction to this revolutionary development, thousands of anesthesiologists publicly said things like "what matters is not the technique but the skill of the physician", "good anesthesiologists don't make mistakes like that in the first place", "but this new technique takes 1%-3% longer than the previous one" or similar.

Utterly unthinkable, isn't it?

Yet in software engineering, this is exactly what has been happening every day for more than a decade.

Re: Memory Safe Languages in Android 13

#357

Post by Gigachad »

logicchains wrote: post #352
Gigachad wrote: post #282

Earlier quoted context omitted.

C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…

>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.

We probably need to bring in some kind of criminal liability for the companies that only cared about time to market and put their users at risk.

After memory safe languages become a bit more battle tested, C/++ needs to be regulated like asbestos.

Re: Memory Safe Languages in Android 13

#358

Post by uluyol »

lzooz wrote: post #4
binkHN wrote: post #3

From the bottom of the article: > As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!

How about speed from going from C/C++ to Java/Kotlin? Have they considered that even?

Much of Android is written in Java/Kotlin. Transitions from the JVM to C/Rust and back are not going to be free due to extra wrappers and the inability to optimize across the boundary. So for some usecases Java will be faster. But anything CPU or memory intensive will probably be cheaper in Rust.

Re: Memory Safe Languages in Android 13

#359

Post by dagmx »

nneonneo wrote: post #188
netr0ute wrote: post #171

Earlier quoted context omitted.

let mut line = String::new(); stdin().read_line(&mut line)?; This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do std::string input; std::cin >> input; and have it Just Work. Why can't Rust do something similar?

Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do? Here's another example. C++ lets you do this: long input; std::cin >> input; process(input); and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or…

I have to say I appreciate when folks like yourself explain the subtle flaws in very simple code.

It’s been really eye opening as I do security analysis of C++ projects how many foot guns are in a ton of codebases that now need so much scaffolding to handle properly, after they’ve done damage.

With Rust, my first pass is usually the right pass.

Re: Memory Safe Languages in Android 13

#360

Post by nickm12 »

modshatereality wrote: post #59

is this a good way to spend developer time? How about *removing* all of the middle-man bloatware instead of wasting how many dev-years rewriting it (edit: and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool). just give me the direct linux experience we all deserve instead of this garbo spamflinger middlewear that google leverages to keep you depende…

"...wasting how many dev-years rewriting it"

It sounds like you didn't read the blog post. The whole point is that they are not rewriting code, but writing new code in memory-safe languages (including "niche" languages like Java). This strategy is paying off with fewer severe vulnerabilities due to memory safety bugs.

Post reply on HN