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

241–250 of 377 posts

Re: Serious Chrome zero-day

#241

Post by _pmf_ »

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…

Then I'll be that guy that tells you that including side channels after side channels (WebGL, WebUSB, FileStream), each with byzantine security features haphazardly tacked on, is the actual problem.

Re: Serious Chrome zero-day

#242

Post by einr »

city41 wrote: post #95
crushcrashcrush wrote: post #9

Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?

I have made several attempts to switch to Firefox. But for me at least Firefox seems to crash about once a day. I don't think Chrome has ever crashed on me in about a decade of using it, and crashed tabs are extremely rare.

I've been using Firefox exclusively ever since it was Firebird 0.7, every day, on scores of computers using Linux and BSD and Windows from 95 to 10, and I just don't remember it ever really crashing. I'm sure it's happened at some point, but it's rare enough that I can't recall a single instance.

But I've never used it on macOS, so I'm guessing that's what you're doing. I hear the Mac port is worse than the others in terms of stability and performance. If true, that's a pity, but Firefox really is rock solid on other platforms.

Re: Serious Chrome zero-day

#243

Post by sanxiyn »

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

The real problem is that the web is now too complex to the point that it's impossible to safely implement it. And W3C keeps trying to add new features to it. At some point we have to stop and consider whether all this cruft is even necessary.

Of course all the cruft is necessary due to compatibility. (Browsers monitor usage statistics and do remove crufts when possible.)

Re: Serious Chrome zero-day

#244

Post by nneonneo »

zetafunction wrote: post #234
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…

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.

So what happened here? There's an in-the-wild exploit that's bypassing sandboxing - so there must be at least two bugs, or the sandbox isn't tight enough (which, for Chrome, would surprise the hell out of me).

Re: Serious Chrome zero-day

#246

Post by pjmlp »

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…

Linux is another good example how C doesn't cut it, even among top developers.

They have a very strict patch review process in place.

They have kernel static analysers.

The kernel has been adding security gates through the years.

Yet 68% of 2018 CVE's were caused by memory corruption bugs, with the others ones left out being UB, numeric conversions, and very tiny fraction remaining of the logic error kind that are bound to happen in any programming language. [1]

Just the other day we had a Linux 5.0 pre-release bug caused by a GCC "optimization".

Oracle went with hardware memory tagging for Solaris/SPARC, Apple is following along on iOS, Microsoft security advisory (as of Blue Hat conf) is C# + Rust + constrained C++ [2], Google is pushing for hardware memory tagging, Kernel Self Protection Project, constraining what the NDK is allowed to do and Fuchsia is getting more Rust/Go modules by the day.

What is clear is that hoping for the best and the mythical 10x developers that write perfect C and C++ code won't ever happen.

[1] Source, Google talk at Linux Kernel Summit 2018.

[2] Following the Core Guidelines

Re: Serious Chrome zero-day

#247

Post by throwaway12iii »

pcwalton wrote: post #199
wahern wrote: post #181

Earlier quoted context omitted.

Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and t…

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift…

From the rust Oxidization page (hip name):

- "Crossing the C++/Rust boundary can be difficult."

- "For components that are relatively standalone, with small and simple APIs."

- "This minimizes the C++/Rust boundary layer issues."

Not only does Rust not have a good JavaScript integration story, it doesn't have a good C++ integration story.

Most of Firefox is still (8 years later) not written in Rust.

Chrome with C++ has a waaaaay better safety record than Firefox. Guess what? The C++ in Chrome tries to ensure memory safety for JS.

The C++ Chrome tooling does a better job of memory safety as a whole system than Firefox.

Re: Serious Chrome zero-day

#248

Post by rocqua »

pcwalton wrote: post #226
wahern wrote: post #217

Earlier quoted context omitted.

I never said it was. I said it implicated JIT'd code and the complex GC subsystem. The context is a JavaScript ArrayBuffer, the very type of object that JIT engines are built to optimize access to, and thus it's reasonable to infer that there may be some sort of cross-runtime scoping aspect at play. Such code by definition not only bypasses language protections, most relevant to this case it implicates interfaces tha…

Yes, there has to be some unsafe glue code somewhere. So what? You write it once and wrap it in a safe interface (there are at least three relevant options in the crate ecosystem that I mentioned). That way, programmers who hack on FileBuffer don't have to worry about introducing zero-days like this. This is not feasible in C++, because the language isn't safe to begin with.

JIT isnt unsafe glue. The very core concept of JIT breaks all compiler guarantees at runtime.

Re: Serious Chrome zero-day

#249

Post by pjmlp »

wahern wrote: post #181
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…

Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and t…

Regular PC world has plenty of experience in multi-language integration.

SOM in OS/2, COM/UWP on Windows, JVM, .NET, ILM and TIMI on IBM mainframes.

Only UNIX world has been relatively poor in this regard, sticking with bare C FFI.

Re: Serious Chrome zero-day

#250

Post by pjmlp »

pcwalton wrote: post #199
wahern wrote: post #181

Earlier quoted context omitted.

Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and t…

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift…

You are forgeting SOM and COM/UWP.

Actually something where Rust still fails short of being an alternative to Delphi/C++ on Windows, regarding tooling and productivity.

Looking forward to the HoloLens collaboration or Microsoft now pushing for Rust on their security guidelines will actually improve that experience.

Post reply on HN