201–210 of 377 posts
clicks Help->About Google Chrome Updates are disabled by your administrator. welp.
What you should do is find out how the referenced vulnerability works and then exploit it to bypass administrator controls so you can update.
Earlier quoted context omitted.
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.
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…
> 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.
In the context of a bug involving JavaScript ArrayBuffers (where JIT compilers are designed to optimize away both FFI accessors and bounds checks) and asynchronous events I think it would be prudent to withhold judgment.
Earlier 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…
So glad the article cleared that up.
Earlier quoted context omitted.
So what language should they've written it in?
I'll be that guy. :) Rust. (I'm a front-end dev. I have no dog in this fight.)
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…
I think it's a time that we should get rid of this notion of "perfectly safe code in the perfect world". It might be possible if the code doesn't change for million years, but that's not how the world works - things keep changing, the specs, the requirements and the users. Bugs are created every day. It's not about safety as a static property, but it is about the safety in an ever-changing world. As Bruce Schneier pu…
Earlier quoted context omitted.
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…
Can you provide an example of a dangling reference of any type (not just a UAF) being exploitable for RCE in a managed language like Java, Rust, or Go?
The point is that it doesn't matter what language is hosting the JIT. You can write this same bug in a program with a JIT hosted on the JVM, in a Rust program, or in a Go program. The code generated by the JIT is the equivalent of C FFI or an unsafe block, which completely ignores your "managed" language. V8 calls directly into and out of the JIT heap with a couple stubs a handful of instructions long, code in the JIT heap is whatever you generated, and can do whatever you told it to.
Earlier quoted context omitted.
Can you provide an example of a dangling reference of any type (not just a UAF) being exploitable for RCE in a managed language like Java, Rust, or Go?
> Can you provide an example of a dangling reference of any type (not just a UAF) being exploitable for RCE in a managed language like Java, Rust, or Go? The point is that it doesn't matter what language is hosting the JIT. You can write this same bug in a program with a JIT hosted on the JVM, in a Rust program, or in a Go program. The code generated by the JIT is the equivalent of C FFI or an unsafe block, which com…
Earlier quoted context omitted.
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.
I've never heard of this happening in practice, however.