Serious Chrome zero-day • Hacker News Board

Re: Serious Chrome zero-day

#341

Post by AgentME » Thu, Mar 07, 2019, 7:50 PM UTC

cjones26 wrote: post #39

AgentME wrote: post #18

Earlier quoted context omitted.

If the Electron app never shows untrusted HTML with Javascript enabled, then it's not an issue. Generally, only Electron apps with arbitrary web browsing functionality would do that.

Which is a massive security issue in itself--Electron documentation even warns you about this.

Electron's docs (https://electronjs.org/docs/tutorial/security#isolation-for-...) mention that you should webview or BrowserView with a certain option with untrusted content, not that it shouldn't be done at all.

Re: Serious Chrome zero-day

#342

Post by sureaboutthis » Thu, Mar 07, 2019, 7:59 PM UTC

setr wrote: post #307

sureaboutthis wrote: post #288

Earlier quoted context omitted.

And almost every operating system in the world is written in C by top developers who are in the know. If there was a better way, everyone would do it, but they don't. Let's quit pretending that any software written in any other language would be more secure and have less bugs.

A monopoly is naturally self-sustaining. It's absurd to think there couldn't possibly be a "better way", that C is somehow perfect in its niche (that all-encompassing niche, that once covered anything and everything that wasn't grabbed by perl); But major experience in developing OS's is with C.. the knowledge, experience, tooling, etc depends on C, because C already has complete and total dominance in the area. It's…

If there is a safer, cheaper, faster language to use, someone would be using it. For another language to take C's place, it needs to be at least two of those--maybe all three and more. Market dominance, if there is such a thing in this area, has nothing to do with it.

Re: Serious Chrome zero-day

#343

Post by steveklabnik » Thu, Mar 07, 2019, 8:01 PM UTC

zrm wrote: post #338

steveklabnik wrote: post #332

Earlier quoted context omitted.

What do you prefer about templates? (And yes, I fully support making C++ safer too; the GSL is as close as we're going to get, probably.)

Template metaprogramming, variadic templates, integers as template parameters, etc. Even better would be constexpr user types as template parameters. How about a language that embraces Turing-complete template metaprogramming as a thing to design in on purpose rather than something discovered after the fact to be more useful than anticipated. Have the utility without the ugly.

Cool, thanks! I think you'll be happy with Rust eventually; a lot of this is coming, likely this year. It's on the roadmap, though that has to be approved first. (The thing that isn't yet is variadrics, not sure when that'll happen.)

(And the reason it's taking such a while is that we are actually doing that...)

Re: Serious Chrome zero-day

#344

Post by Johnny555 » Thu, Mar 07, 2019, 8:21 PM UTC

chii wrote: post #157

Johnny555 wrote: post #129

Earlier quoted context omitted.

I can write a safe C++ app on my own But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".

> I can write a safe C++ app on my own >> But only if you don't use any external libraries using an external library is not "on your own"

Don't most people link at least with basic libraries to help with I/O and other standard operating system interfaces?

Do many people really use the kernel syscall interface directly?

Re: Serious Chrome zero-day

#345

Post by setr » Thu, Mar 07, 2019, 8:37 PM UTC

sureaboutthis wrote: post #342

setr wrote: post #307

Earlier quoted context omitted.

A monopoly is naturally self-sustaining. It's absurd to think there couldn't possibly be a "better way", that C is somehow perfect in its niche (that all-encompassing niche, that once covered anything and everything that wasn't grabbed by perl); But major experience in developing OS's is with C.. the knowledge, experience, tooling, etc depends on C, because C already has complete and total dominance in the area. It's…

If there is a safer, cheaper, faster language to use, someone would be using it. For another language to take C's place, it needs to be at least two of those--maybe all three and more. Market dominance, if there is such a thing in this area, has nothing to do with it.

Market dominance can be read as ecosystem dominance, and that reading obviously exists. More specifically, the C language could be completely worthless on its own, but made good enough to be usable through tooling (eg fuzzing, valgrind, etc). As it turns out, theres a lot more involved in writing an OS than just the language; and its all so conjoined at the hip, enough so that it makes it quite difficult to change just the language. But this is an argument that despite C’s flaws, its existence is on the whole preferrable to a total rewrite.

>If there is a safer, cheaper, faster language to use, someone would be using it

someone is using other languages. Urbit, redox, lisp machines, mirage are all not-c systems/OSs. But you aren’t talking about writing an OS, you’re talking about writing a popular OS. Of which there are basically three worth noting, all of which happen to have sprung up around a similar timeframe, coincidentally when C was at its most popular...

You seem to have confused the software industry for some kind of meritocracy... it is not. It follows trends harder than than the fashion industry. Look ...anywhere... for examples: OS, DB, language, game design and tooling, the AI winters, the .com crash, everything about the web, HN itself, etc. Hell, your own argument is just bandwagoning, with nothing about the technical merit (smarter people than I are using it, thus I should... is exactly how we end up in this state)

Re: Serious Chrome zero-day

#346

Post by ErikCorry » Thu, Mar 07, 2019, 9:01 PM UTC

duneroadrunner wrote: post #283

duneroadrunner wrote: post #188

Earlier quoted context omitted.

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: DOMArr…

Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issue. (Or at least not a typical one.) [1] https://chromium.googlesource.com/chromium/src/+/master/thir...

Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

Re: Serious Chrome zero-day

#347

Post by wahern » Thu, Mar 07, 2019, 11:03 PM UTC

titzer wrote: post #278

wahern wrote: post #203

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…

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

It does for native arrays, at least:

> This is the incorrect optimization we’re looking for. JavaScript array accesses are guarded by CheckBounds nodes, which ensure that the index falls within the array bounds. If the optimizer can determine statically that the index is always in-bounds, it can eliminate the CheckBounds node. Image tying the index to the result of Object.is: since the typing information is off, we could make the analyzer think the index is always in-bounds, while it can be out-of-bounds at runtime. The optimizer will incorrectly eliminate CheckBounds, giving us OOB access to a JS array, which we can use to construct more powerful exploitation primitives.

https://abiondo.me/2019/01/02/exploiting-math-expm1-v8/

Re: Serious Chrome zero-day

#348

Post by duneroadrunner » Thu, Mar 07, 2019, 11:46 PM UTC

ErikCorry wrote: post #346

duneroadrunner wrote: post #283

Earlier quoted context omitted.

Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issue. (Or at least not a typical one.) [1] https://chromium.googlesource.com/chromium/src/+/master/thir...

Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/... The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromi…

ArrayBufferBuilder isn't, but DOMArrayBuffer seems to be a GC managed type [1], right? And, before the patch, the DOMArrayBuffer held a "refcounting pointer" potentially targeting raw_data_'s reference counted ArrayBuffer, right? I don't see any immediately apparent use-after-free with this, so I assume raw_data_'s ArrayBuffer is being messed with elsewhere? As someone who worked on the code, do you have an idea/hunch about where the invalid memory access actually occurs?

https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...

Re: Serious Chrome zero-day

#349

Post by intherdfield » Fri, Mar 08, 2019, 1:27 AM UTC

nneonneo wrote: post #244

zetafunction wrote: post #234

Earlier quoted context omitted.

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

"The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape."

https://security.googleblog.com/2019/03/disclosing-vulnerabi...

Re: Serious Chrome zero-day

#350

Post by chii » Fri, Mar 08, 2019, 2:34 AM UTC

dymk wrote: post #166

chii wrote: post #157

Earlier quoted context omitted.

> I can write a safe C++ app on my own >> But only if you don't use any external libraries using an external library is not "on your own"

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

The point i was making is that such boundary doesn't exist - no one can write everything "on their own".

Therefore, language features to prevent a class of exploits should be a high priority when considering a project.