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

131–140 of 377 posts

Re: Serious Chrome zero-day

#131

Post by catach »

core-questions wrote: post #102
ancarda wrote: post #91

Earlier quoted context omitted.

C++, as that was a reasonable choice in Bits of Firefox are written in Rust, so Chrome could in theory under go the same "oxidation" (gradually replace the C++ code with Rust). Edit: Clarify that Chrome was released in 2008 but was likely in development for some time before that.

> Chrome was released in 2008 but was likely in development for some time before that. Well, sure, didn't it end up taking WebKit from Safari, which was C++, because it came from KDE Konqueror's KHTML?

Yes, Chrome was a fork.

Re: Serious Chrome zero-day

#132

Post by staticassertion »

kllrnohj wrote: post #128
staticassertion wrote: post #93

Earlier quoted context omitted.

The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many millions of dollars, and we don't know what it is. Can we reasonably expect that price to be lower with language X? For many reasons, I would argue 'yes'.

Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage…

To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".

Re: Serious Chrome zero-day

#133

Post by steveklabnik »

naikrovek wrote: post #126
kllrnohj wrote: post #117

Earlier quoted context omitted.

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.

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.)

Re: Serious Chrome zero-day

#134

Post by kllrnohj »

staticassertion wrote: post #125
kllrnohj wrote: post #117

Earlier quoted context omitted.

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.

I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue. 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++. I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm…

> 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 scream "you cannot use this language safely!!!", now does it?

I would certainly argue for something like Rust instead if starting from scratch, though, but just because A is better than B doesn't make B unusable trash, either.

Re: Serious Chrome zero-day

#135

Post by pcwalton »

bla3 wrote: post #124
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…

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 trusted code that can nevertheless be exploited remotely.

Re: Serious Chrome zero-day

#136

Post by kllrnohj »

naikrovek wrote: post #126
kllrnohj wrote: post #117

Earlier quoted context omitted.

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.

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…

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust.

You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI.

Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

Re: Serious Chrome zero-day

#137

Post by staticassertion »

kllrnohj wrote: post #134
staticassertion wrote: post #125

Earlier quoted context omitted.

I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue. 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++. I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm…

> 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 thousands of memory safety vulnerabilities, but not many make it to ITW exploits. This case is special because users actually suffered because of it. It isn't fair to say they've had "one security issue", certainly, just one that's had major user impact.

I'm not judging C++ or the choice to use it. I am saying that this is an example of a very hardened system not being able to compensate for memory unsafety.

Re: Serious Chrome zero-day

#138

Post by jsjohnst »

jlgaddis wrote: post #114
flukus wrote: post #113

Earlier quoted context omitted.

D was released in 2001, KHTML in 1998, it's like suggesting they should have written vim in java.

... and Chrome in 2008.

Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.

Re: Serious Chrome zero-day

#139

Post by pcwalton »

naikrovek wrote: post #126
kllrnohj wrote: post #117

Earlier quoted context omitted.

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.

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; it's no more safe if you use that keyword to do the same things that are done in C++.

Yes, it is, because the language has the concept of safe code to begin with. The problem with C++ is that all C++ code could potentially be unsafe.

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust.

This is a very confused comment. Rust is also written in Rust. If you're thinking of LLVM, sure, the Rust compiler uses that, but LLVM is nowhere to be found in products written in Rust that are shipped to users. What matters is how safe the runtime is, and there's no real difference between Go and Rust in this regard. Go might theoretically have some kind of edge over Rust in safety in that it calls syscalls directly instead of going through libc, but I highly doubt it matters in practice, because (a) the libc wrappers are a drop in the bucket compared to the complexity of the kernel; (b) Go only does that on Linux these days anyhow.

Re: Serious Chrome zero-day

#140

Post by nitwit005 »

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…

In a general sense, I'd agree, but from the description in that article, it's interaction with native files or file dialogs. Even if you use Java, you're susceptible to this sort of bug, because your Java code calls into layer of C code to handle the native interaction.

Realistically, any browser is probably going to have a decent amount of unsafe code surrounding the native windowing, files, graphics, and so on.

Post reply on HN