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

Serious Chrome zero-day

nakedsecurity.sophos.com

Post reply on HN
Print view View original

171–180 of 377 posts

Re: Serious Chrome zero-day

#171

Post by [deleted] »

steveklabnik wrote: post #133
naikrovek wrote: post #126

Earlier quoted context omitted.

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…

> Rust has unsafe all over the place This does not match my experience nor numbers I’ve seen. What leads you to say this? (Also, other than LLVM, Rust is written in Rust. And when cranelift lands, you could remove that too.)

[deleted]

Re: Serious Chrome zero-day

#172

Post by [deleted] »

dymk wrote: post #166
chii wrote: post #157

Earlier quoted context omitted.

> I can write a safe C++ app on my own >> But only if you don't use any external libraries using an external library is not "on your own"

Can you use the STL? What boundary is considered trusted?

[deleted]

Re: Serious Chrome zero-day

#174

Post by kerng »

kllrnohj wrote: post #117
staticassertion wrote: post #86

Earlier quoted context omitted.

A memory safe one. There are many of them. They could build their own if they chose to - they've built multiple languages in the past. Picking a language for the Chrome team doesn't seem practical - we all know where your question is going to head. The point is they have to not pick C++. Again, they've invested many, many millions of dollars into security. Let's not pretend that they're priced out of using another la…

Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.

C++ is a write only language. Too many complex features that are used in ways that only the author of the code understands at the time of writing - or thinks of understanding at the time of writing even.

Re: Serious Chrome zero-day

#175

Post by platinumrad »

karavelov wrote: post #165
naikrovek wrote: post #126

Earlier quoted context omitted.

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…

Apart from memory safety issues, there are type safety issues that can cause equal security harm. Go's approach of casting interface{} back and forth is as dangerous as allowing malloc/free. The worst part is that the language designers don't see this as a problem.

interface{} is not great but it is not void *. Type assertions (casts) on interface{} are typechecked at runtime and failed type assertions on interface{} cannot violate memory safety.

Re: Serious Chrome zero-day

#176

Post by htfy96 »

bauerd wrote: post #87
elorant wrote: post #82

Earlier quoted context omitted.

So what language should they've written it in?

Use-after-free is ruled out by e.g. Rust's type system

Nope. It's only true when all your code use safe subset/built upon a perfectly correct unsafe base (which is inevitable in a project like Chromium) with correct usage. Otherwise a single misused external call with unsanitized value can ruin all of your security guarantee.

Re: Serious Chrome zero-day

#177

Post by stcredzero »

pcwalton wrote: post #135
bla3 wrote: post #124

Earlier quoted context omitted.

If there's ever a project as large as Chrome written in a non-C++ language, I guarantee you it will have these bugs as well -- due to use of `unsafe`, or bugs in the compiler, or what have you.

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one. †I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in t…

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one.

If enough of a complex system is written in a language or run on a managed runtime that eliminates entire classes of exploits, then the developers will wind up implementing some optimizations and/or a way to write applications/plugins/extensions in C/C++. These mechanisms will open the doors to those exploits again.

(At least for now. Going forwards, I think we might be able to solve this one.)

Re: Serious Chrome zero-day

#178

Post by est31 »

staticassertion wrote: post #137
kllrnohj wrote: post #134

Earlier quoted context omitted.

> What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all…

Well, that's not really a fair interpretation of my argument, I'd say. My argument is: * We have a production, widely used codebase * This codebase is in C++ * This codebase has probably the most significant efforts to secure it of anything of its size, or at least it's in the top 5 * This codebase suffered enouguh critical vulnerabilities for users to be attacked in the wild So let's be clear - Chrome suffers from t…

> not being able to compensate for memory unsafety.

This is a bit of a simplistic view tbh. They have managed to drive up costs for 0 days on the black market. They have introduced auto-updating browsers to get security patches to users quickly. They have managed to reduce the number of security exploits. This is a big feat and major progress.

They have compensated for memory unsafety quite effectively. Maybe not perfectly, but well enough.

Yes, memory safe languages are wonderful. I myself am a rustacean and LOVE to RIIR. But their efforts weren't in vain.

Should they start thinking about adopting a memory safe language like Rust or Wuffs? Definitely.

Re: Serious Chrome zero-day

#179

Post by baby »

staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

Hence why it is freaking amazing to follow what Firefox is doing with Rust.

Re: Serious Chrome zero-day

#180

Post by baby »

elorant wrote: post #82
staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

So what language should they've written it in?

Rust.
Post reply on HN