Live data from Hacker News

Chrome zero-day released on GitHub – fixed on V8 but still works on latest

github.com

131–140 of 160 posts

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#131

Earlier quoted context omitted.

It isn't particularly safe compared to having JS disabled. RCE exploits, stealthy CSRFs, etc. that work with JS disabled are exceedingly rare compared their JS counterparts. This is quantifiable , not "alarmist".

There are plenty of stealthy CSRFs that don't require javascript, but you probably meant stealthy XSS

I did not.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#132

Earlier quoted context omitted.

Well the age sets an upper bound for the effort put into it, doesn't it?

Not really. I was much more focused and arguably a better coder at 18, albeit a somewhat less knowledgeable one. At 26 I have twice the experience but only a third of the motivation and focus. When you're younger you do stuff just find out whether you can, when you're older you already know you could and decide not to do anything. It's exceedingly rare I'll find something interesting enough that'll keep me coding for…

> My money will always be on the 18 year olds.

That is not only problematic but also illegal in certain contexts

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#133
post #52

Earlier quoted context omitted.

For anyone else wanting to analyze this: echo '\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48 \x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48 \x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9 \x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b \x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\…

Minor nit, but I suppose you mean "echo -ne" ?

I guess the newline that echo without -n would add doesn't matter that much.

OTOH -e, depending on your shell, is either necessary (e.g. bash), or unnecessary but harmless (e.g. zsh) or insufficient (e.g. dash). If you want to print binary stuff portably, you need to use printf(1).

(Shameless plug: you can use https://github.com/jwilk/printfify to generate printf commands for binary files.)

In this case, base64 encoding is much more efficient:

  /EiD5PDowAAAAEFRQVBSUVZIMdJlSItSYEiLUhhIi1IgSItyUEgPt0pKTTHJSDHArDxhfAIs
  IEHByQ1BAcHi7VJBUUiLUiCLQjxIAdCLgIgAAABIhcB0Z0gB0FCLSBhEi0AgSQHQ41ZI/8lB
  izSISAHWTTHJSDHArEHByQ1BAcE44HXxTANMJAhFOdF12FhEi0AkSQHQZkGLDEhEi0AcSQHQ
  QYsEiEgB0EFYQVheWVpBWEFZQVpIg+wgQVL/4FhBWVpIixLpV////11IugEAAAAAAAAASI2N
  AQEAAEG6MYtvh//Vu/C1olZBuqaVvZ3/1UiDxCg8BnwKgPvgdQW7RxNyb2oAWUGJ2v/VY2Fs
  Yy5leGUA

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#134
post #7
post #2

So what I really want to know is: what happens at Cloudflare--which uses v8 to implement Cloudflare Workers in shared memory space--when this kind of stuff happens? (Their use is in some sense way more "out on a limb" than a web browser, where you would have to wait for someone to come to your likely-niche page rather than just push the attack to get run everywhere.)

This is what happens: Within an hour of V8 pushing the fix for this, our build automation alerted me that it had picked up the patch and built a new release of the Workers Runtime for us. I clicked a button to start rolling it out. After quick one-click approvals from EM and SRE, the release went to canary. After running there for a short time to verify no problems, I clicked to roll it out world-wide, which is in pr…

I think you are right — it is debatable [1]. I would argue that it is easier to find ways to exploit determinism of scheduling/allocation than finding ways to exploit humans.

[1] https://hovav.net/ucsd/dist/cloudsec.pdf

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#135
post #7
post #2

So what I really want to know is: what happens at Cloudflare--which uses v8 to implement Cloudflare Workers in shared memory space--when this kind of stuff happens? (Their use is in some sense way more "out on a limb" than a web browser, where you would have to wait for someone to come to your likely-niche page rather than just push the attack to get run everywhere.)

This is what happens: Within an hour of V8 pushing the fix for this, our build automation alerted me that it had picked up the patch and built a new release of the Workers Runtime for us. I clicked a button to start rolling it out. After quick one-click approvals from EM and SRE, the release went to canary. After running there for a short time to verify no problems, I clicked to roll it out world-wide, which is in pr…

That's impressive, in fact I would argue that this is as close to best-practice as you can get. I would love to read a blog post with details how you set this up!

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#136

Earlier quoted context omitted.

You pretty much can't, because once memory has been written to at runtime it is assumed to be untrusted. JIT in and of itself is a W^X violation, so the only real solution is to not use it when security over performance is preferred.

Remove support for raw data types from JS. Remove Array buffers, remove blob support, remove anything which can be used to assembly a continuous binary without passing some sanitation.

That isn't sufficient. You know why?

    exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*")
Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#138
post #35
post #25

Earlier quoted context omitted.

Thanks for the response! This didn't really answer what I was curious about, though: like, you answered what happens during the minutes after the fix being pushed, but I am curious about the minutes after the exploit being released, as the mention of "zero day" made me think that this bug could only have been fixed in the past few hours (and so there were likely hours of Cloudflare going "omg what now?" with engineer…

> which patched the bug in the V8 code last week This does not appear to be true. AFAICT the first patch was merged today: https://chromium-review.googlesource.com/c/v8/v8/+/2820971 (It was then rapidly cherry-picked into release branches, after which our automation picked it up.) > I am curious about this because I want to better understand the mitigations in place by a service such as Cloudflare, as I am interested…

Dynamic worker isolation is something something I have dabbled with. I’ve been trying to figure out that if, once a misbehaving isolate is.. isolated it is possible to scrutinize its behavior to catch it in the act. What do you think? Would something like that even be useful? It seems to me that maybe if an isolate is confirmed malicious you can backtrack and identify data leaks.

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#139

Earlier quoted context omitted.

Remove support for raw data types from JS. Remove Array buffers, remove blob support, remove anything which can be used to assembly a continuous binary without passing some sanitation.

That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.

1. String are not executable code

2. Can be sanitised to be valid UTF-16

3. Can be intentionally mangled in memory to prevent abuse

Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest

#140

Ah yes. Perfect timing. Just 2 days after I was heavily downvoted for saying that you're not particularly safe if you don't disable JS. This absolutely made my day. HN truly is a source of nonstop entertainment.

I could go ahead and say diable internet unless you dont want to be particularly safe. I mean there are CPU level zero days. But on a serious note, how would one protect oneself from Apps other than browser and talk to internet? I mean we can't ask regular users to learn and turn off stuff.
Post reply on HN