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

501–510 of 606 posts

Re: Memory Safe Languages in Android 13

#501

Post by UncleMeat »

josefx wrote: post #460
simiones wrote: post #443

Earlier quoted context omitted.

> > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.

> It is a somewhat common attitude in this type of thread. Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .

And yet, you can happily have a UAF through a string_view.

This is not about C++ developers using old school C approaches. The language is fundamentally dangerous. There were huge efforts within Chrome to get all memory managed by smart pointers even more powerful than those offered by the standard, and they still have UAFs all the time.

Re: Memory Safe Languages in Android 13

#502

Post by humanrebar »

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.

Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this.

It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices.

I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies updated and up to standards. A lot of those are written in C and C++, probably.

Re: Memory Safe Languages in Android 13

#503

Post by UncleMeat »

ghostwriter wrote: post #238
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…

> 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…

And yet, people still store a string_view in a field and then access it past the lifetime of the underlying string.

Yes, things have gotten better. Smart pointers are a godsend. Sanitizers are a godsend. Various static analysis tools work pretty well.

But even codebases that adopt all of these things religiously still are riddled with security vulns.

Re: Memory Safe Languages in Android 13

#504

Post by humanrebar »

clnq wrote: post #348
raggi wrote: post #343

Earlier quoted context omitted.

You can do some basic analysis about your assumption: go pick out a bunch of the CVEs and look at the age and style of the source code. Another approximation is to look at the Android source tree to see what proportion of it is as old as you assume in your argument. There are 431 results for a search `"Copyright 200" filepath:. \.cpp`. There are 7465 results for `"Copyright 201" filepath:. \.cpp`. 4152 results for `"…

Thanks, that was very insightful. Yes, as you say, the copyright year in a .cpp/.h doesn't necessarily say whether C++ 11 features are used. I've looked at many "Copyright 201" and "Copyright 202" headers. I needed to see more use of C++ 11 or equivalent smart pointers or containers to say that this codebase uses modern C++ memory safety features. Other modern C++ features (like std::make_pair that you mention) are e…

I mentioned this elsewhere, but the real A/B test here would be to do a rewrite in the existing language and compare it to doing a rewrite in Rust with respect to memory safety, etc.

Re: Memory Safe Languages in Android 13

#505

Post by quotemstr »

p-e-w wrote: post #356
yosefk wrote: post #199

Earlier quoted context omitted.

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…

> Utterly unthinkable, isn't it?

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

Consider what happened to poor Semmelweis when he discovered in the middle of the 19th century that hand-washing improved medical outcomes: doctors of the time were too proud to accept his results and drove him out of the profession (and to his early grave) rather than change their practices.

All these people who insist on continuing to write new C programs have the same mentality as those doctors who refused to wash their hands.

Re: Memory Safe Languages in Android 13

#506

Post by UncleMeat »

humanrebar wrote: post #502
Ar-Curunir wrote: post #255

Earlier quoted context omitted.

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.

Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this. It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices. I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies…

//third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).

Re: Memory Safe Languages in Android 13

#507

Post by UncleMeat »

rob74 wrote: post #412
kaba0 wrote: post #396

Earlier quoted context omitted.

Google’s C++ coding guide is (was?) not really up-to-date, so there is that. Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these . Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

> Besides the bottom of the stack, managed languages are more than fast enough for nigh everything And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...

There are plenty of people who want to write in Rust for the fun of it. But I'm not aware of too many people saying that you should avoid writing a web application in java/python/js in favor of rust. Pretty much the only people being told to stop doing what they are doing are the people starting new projects that process untrusted data in C and C++.

Re: Memory Safe Languages in Android 13

#508

Post by humanrebar »

yosefk wrote: post #212
Taywee wrote: post #209

Earlier quoted context omitted.

> which in 20 years it will, and I wasn't that hopeful 20 years ago That's too optimistic. C++ would easily die in 20 years if it didn't already have 30+ years of still-active legacy that can't easily be converted or rewritten. I've recently even had to start new projects in C++ because platforms I depend on demand it or because I have to interface with existing code and libraries that still only exist as C++. I'm no…

Dead - no, dying COBOL-style - quite possibly.

How much C and C++ do we have now? How much COBOL did we have at it's peak? I'm not sure the analogy holds for that reason alone.

What if the better analogy is updating building codes in Manhattan?

Re: Memory Safe Languages in Android 13

#509

Post by heather45879 »

Thorrez wrote: post #424
heather45879 wrote: post #341

Earlier quoted context omitted.

Syntax coloring would make it worse because coloring the :: independently of the surrounding tokens will make them stand out even more as a group. Rust is safe but it’s at least as ugly as C++.

It depends on how the coloring is done. If the background is white, the words are black and the :: are gray, the :: won't stand out.

True, but why bother with the symbols in the first place? User experience is just as important for developers reading/writing text and languages are typically created behind closed doors with a small engineering team only.

Guido got a lot right with Python because it’s clean and easy to jump in. Minimal cognitive load. But still very powerful.

Re: Memory Safe Languages in Android 13

#510

Post by UncleMeat »

throw827474737 wrote: post #479
raggi wrote: post #347

Earlier quoted context omitted.

True, but what is said is: We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabil…

They "believe" the major shift is due to Rust, while they continously improve also their C++ tools, and the count in also all violations (even mabe more theoretical ones?) found by those .. I have no doubts about the actual claim, but especially this quite sounds like they may have made more out of this correlation==causation than there maybe is, I believe ;)

I know some of the people who own the tools described above. I can assure you that if those tools were the primary cause of the reduction in vuln they'd be screaming it from the hilltops. A huge amount of work at Google goes into answering questions like "what actually accounts for this change." This is one of the benefits of the promo culture that is often criticized.
Post reply on HN