Serious Chrome zero-day • Hacker News Board

Re: Serious Chrome zero-day

#181

Post by wahern » Thu, Mar 07, 2019, 1:50 AM UTC

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 then one can have a meaningful discussion about memory safe languages. But remove those and the vast majority of Chrome bugs would also disappear. Those are the places of highest complexity while also being the areas which no language offers any meaningful assistance.

And this is why I think it's crazy that the WebAssembly folks are dead set on a specification that presumes and requires tight, direct object bindings between the host and the WebAssembly VM, particularly wrt JavaScript GC integration, as opposed to using indirect references with a clear contract that employ proxy objects for anchoring--in effect a sort of runtime sandboxing which falls short of IPC but which substantially circumscribes system complexity (e.g. invisible data dependencies) and substantially preserves the ability for memory-safe host languages (compilers and runtimes) to meaningfully ensure their invariants.

What we need more than yet another memory-safe language is the motivation and experience in multi-language integration. What we're getting are another generation of programmers recapitulating many unforced errors. Memory-safe languages aren't new. Nor are memory-safe and ergonomic languages. Nor is, for that matter, the thinking that one can throw a single language at a complex problem despite the entire history of computer science being an unending parade of new languages and optimization models with poor integration stories. Bare C FFI is only the most minimal and easiest requirement to get correct when it comes to integration. There's so much more to the problem.

Re: Serious Chrome zero-day

#182

Post by driverdan » Thu, Mar 07, 2019, 1:50 AM UTC

tcbasche wrote: post #31

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 gave Firefox an honest go, but some web apps just don't work 100% in it. Chrome does not have this issue. Most of us drive cars filled with fuel from evil oil companies, why do we all drive cars?

Which apps don't work in Firefox? I've never encountered one.

Re: Serious Chrome zero-day

#183

Post by pcwalton » Thu, Mar 07, 2019, 1:55 AM UTC

tedunangst wrote: post #159

pcwalton wrote: post #149

Earlier quoted context omitted.

That seems to be this one: https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-... It's a straightforward miscompilation. I'm not sure why they even classify it as a vulnerability. From Microsoft, per the article: "The said vulnerability is about downloading and running untrusted code, which has always existed in all releases prior VS2017 Update 9 that supported lambdas. The scenario is not common coding prac…

> If you’re still on the fence about deploying this update, we would consider it Important since it could allow for attacker-controlled code to execute at the level of the logged on user. What does that even mean? I download some c++ code from the internet, compile it, run it, and... it runs as my user?

Yeah, I think it means just that.

I guess there is some conceivable exploit where you compile some hostile code written in a safe language to C++ with MSVC and then run it, and the attacker could exploit this bug somehow? But who does that?

Re: Serious Chrome zero-day

#184

Post by Miltnoid » Thu, Mar 07, 2019, 1:56 AM UTC

Agathos wrote: post #169

dymk wrote: post #166

Earlier quoted context omitted.

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

I can trust the compiler... I hope?

Use CompCert! (And C instead of C++)

Re: Serious Chrome zero-day

#185

Post by roca » Thu, Mar 07, 2019, 1:58 AM UTC

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…

My project currently has 104366 lines of Rust code and 174 uses of 'unsafe' (many of which are somewhat spurious, like usage of `mmap` and other system calls that don't have safe wrappers in external crates). My project does a lot of low-level stuff (e.g. ptracing, sharing memory with C++ code in other processes) and has lots of crazy low-level optimizations but still only has one use of 'unsafe' per 600 lines of code. I haven't made any particular effort to reduce usage of 'unsafe' either.

> it's no more safe if you use that keyword to do the same things that are done in C++

Sure, but using 'unsafe' everywhere that you would write unsafe C++ code simply isn't idiomatic Rust and except for very specific and limited situations, Rust developers don't do that.

Re: Serious Chrome zero-day

#186

Post by latexr » Thu, Mar 07, 2019, 1:59 AM UTC

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’d like to use Firefox, but their lack of AppleScript supports makes that unfeasible. I could get past its atrocious performance, but not past a missing feature I require multiple times a day.

I don’t use Safari because it lacks other features. I can’t disable JavaScript on a per-site basis, and the content blockers are a joke compared to uBlock Origin.

Most other browsers are Chromium based, so might as well use Chrome.

Re: Serious Chrome zero-day

#187

Post by mnm1 » Thu, Mar 07, 2019, 2:00 AM UTC

Huh? Right now, my Chrome says:

Google Chrome is up to date Version 66.0.3359.117 (Official Build) (64-bit) Automatic updates are turned on Learn more

I guess it's time to just delete this garbage, but I'm wondering why. Clearly there are serious issues with Chrome on OS X.

Re: Serious Chrome zero-day

#188

Post by duneroadrunner » Thu, Mar 07, 2019, 2:01 AM UTC

staticassertion wrote: post #93

peterwwillis wrote: post #84

Earlier quoted context omitted.

No codebase will ever be fully free of security bugs, but having 7 million lines of code definitely doesn't help.

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

I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes:

    DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer());
    
    ...
    
        raw_data_.reset();
    
    ...
    
   return result;

I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5].

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

[4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-point...

[5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

Re: Serious Chrome zero-day

#189

Post by staticassertion » Thu, Mar 07, 2019, 2:08 AM UTC

est31 wrote: post #178

staticassertion wrote: post #137

Earlier quoted context omitted.

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

> This is a bit of a simplistic view tbh.

It's a very literal one.

I think I've been very open about what an accomplishment they've made, and how proud they should be to have kept Chrome users safe for all of these years.

It is exactly because their efforts to secure Chrome are so impressive that I think this event is interesting.

None of what I've said is about Rust or even a suggestion that they shouldn't keep doing what their doing. One ITW exploit in a lifetime of a product is a great track record.

It is merely interesting to observe when herculean efforts fall down.

Re: Serious Chrome zero-day

#190

Post by staticassertion » Thu, Mar 07, 2019, 2:11 AM UTC

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…

> there's zero reason to blame C++

Seems like UAF in C++? So, yes, I feel comfortable blaming C++.

Anyways, I didn't mention memory safe languages in my post, and I'm not even suggesting that Google did anything wrong, or should change their posture in any way. They've been extremely successful.