Why is this blogspam with no information upvoted in the first place? Does anyone enjoy reading this?
The post was awful, but I hadn't heard of this exploit before, and I wasn't patched, so, thanks for that !
Serious Chrome zero-day
271–280 of 377 posts
Re: Serious Chrome zero-day
#272Honest question - why do people use Chrome? It’s from an arguably as-evil company as Facebook. Alternatives exist. What’s the draw?
At work, too many websites for professional use are only working on Chrome, so I need to have it.
Curiously enough, at home I have no problems with firefox, so I guess B2C devs are more conscious than B2B ones !
Re: Serious Chrome zero-day
#273Earlier 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…
GraalVM also has a way to do this - the 'unmanaged' C/C++ is upgraded to be automatically memory managed on the fly by compiling pointers into (gc'd reference, integer field offset) and then redirecting allocations to GCd heaps. There's more to it than that of course, but it means traditional C/C++ using new/delete and GCd languages can interop and coexist in the same process and heaps, and memory management errors in the unmanaged side are caught (cause VM termination).
Re: Serious Chrome zero-day
#274I'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.
Well, humans can't. And computers can't, yet.
Re: Serious Chrome zero-day
#275I'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 bo…
I still wonder what the plans for Fuchsia are. Is Google really thinking about just throwing out the millions of man-years which have been sunk into Linux?
Re: Serious Chrome zero-day
#276Earlier quoted context omitted.
> 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++ h…
> Most of Firefox is still (8 years later) not written in Rust.
In part because 1.0 release of Rust popped up in 2015, not 2011.
Re: Serious Chrome zero-day
#277I'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…
> 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.
No, just no. The data just does not back this up. The vast majority of Chrome bugs are not due to the V8 JIT or GC. Full stop. There are JIT bugs, and there are GC bugs. Some are horrible, exploitable. But on balance they are not the majority, and they often take a lot of expertise to find and exploit. Many, many critical bugs are due to array buffers and lifetime management issues of their backing stores. E.g. just tricking one code path to get the length of an array buffer wrong, and suddenly you've got write access to all of memory. (E.g. I recall a bug we had where a user program could install a JS function as a getter for the 'byteLength' property on an array buffer. One codepath in V8 trusted the result of calling this getter rather than an internal lookup, and boom). But array buffers, JIT bugs, and GC bugs aside, there are just a crapton of bugs that are directly due to manual memory management in C++ and all the other pitfalls of C++. We'd be on much better footing to get rid of C++ altogether, as it is by far the most common source of bugs in Chrome. This is the reason for Oilpan/unified heap. Humans suck at managing memory. Let machines do it, IMO.
> 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
Well feel free to make a proposal. (btw, running out-of-process was one of the selling points of NaCl. It did not work well with web platform API integration. A long, complicated story. The NaCl folks work on Wasm these days).
Re: Serious Chrome zero-day
#278Earlier quoted context omitted.
> 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.
UAF by whom? If it's through a bare reference held in the JavaScript VM where operations don't access the C++ object as a C++ object or as some shared primitive object as in the JVM or CLR, then the error is in maintaining state consistency across distinct environments. Such bugs look exactly the same in every language, although the risk is compounded by (a) JIT'd environments and (b) asynchronous execution. In the c…
> where JIT compilers are designed to optimize away...bounds checks
V8 does not optimize away bounds checks on array buffers. For one thing, array buffers can be detached, so their length can suddenly drop to zero.
Re: Serious Chrome zero-day
#279I'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…
Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++.
An application that:
a) has downloading and executing untrusted code as its main feature
b) supports a ton of media formats, with DRM to boot
c) is going through rapid changes, including adding very complex low-level features like WebUSB, WebGL or WebAssembly.
... will be insecure by design.
It's also very likely that no one will create a browser in C++ again, or in any other language for that matter. Microsoft recently gave up and decided to use Chromium, Opera gave up a long time ago. Chromium itself was forked from WebKit, which is used by Safari. Firefox is the only odd one out, slowly but surely sliding into irrelevance.
Re: Serious Chrome zero-day
#280Earlier quoted context omitted.
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 bo…
I still wonder what the plans for Fuchsia are. Is Google really thinking about just throwing out the millions of man-years which have been sunk into Linux?
The kernel is mostly drivers. If they only support a bit of hardware, they'd be tossing a lot of stuff they don't need.