Live data from Hacker News

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

github.com

31–40 of 160 posts

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

#31
post #29
post #28

Here is an article with a lot more detail (high level, not technical) about this... on a random website none of us have ever heard of and so which might be a phishing attack for people like me who immediately went to Google to find more information (and with a few "shockers" in--such as Chrome and Edge not having patched it yet, despite the patch dropping a week ago--to maybe get some viral sharing, such as what I am…

The screenshot suggests that all you need to do for the exploit to work is to open the html/js file, but doing this on windows just results in "Aw, Snap!" page. Others in this thread have confirmed this.

The article says the exploit code released to GitHub doesn't include a sandbox escape, so that seems about like what I would expect: the renderer crashed. (The screenshot is from the researcher, who either has a more complete implementation with another maybe-undisclosed bug or has simply disabled some sandbox restrictions to help test the exploit in isolation or something.)

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

#32
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…

Forgot to begin post with "Horse's Mouth here".

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

#33
https://therecord.media/security-researcher-drops-chrome-and... says this isn't a fully weaponizable exploit because you still need to escape the Chrome sandbox after using this. But, the researcher shows a screenshot of having started calc.exe which seems like something that'd happen outside the sandbox?

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

#34

https://therecord.media/security-researcher-drops-chrome-and... says this isn't a fully weaponizable exploit because you still need to escape the Chrome sandbox after using this. But, the researcher shows a screenshot of having started calc.exe which seems like something that'd happen outside the sandbox?

I would imagine the researcher showed a screenshot of the exploit being run on a copy of Chrom{e,ium} where he had disabled parts of the sandbox (that, or he has a more complex exploit with another maybe-undisclosed sandbox escape).

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

#35
post #25
post #7

Earlier quoted context omitted.

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…

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 in the security ramifications of doing similar v8 work in distributed systems.

Here's a blog post with some more details about our security model and defenses-in-depth: https://blog.cloudflare.com/mitigating-spectre-and-other-sec...

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

#36
post #25
post #7

Earlier quoted context omitted.

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…

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…

I'd say for the 0-day exploit to affect services like CloudFlare someone would need to run the exploit first on their V8 infrastructure instances.

This would require ahead knowledge of the vulnerability and someone either within CloudFlare or at one of it's used code dependencies to plant malicious code. Since a rolling upgrade seems to be fully automated at CloudFlare and can be done within a few hours for the complete infrastructure, I don't see CF being at high risk here.

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

#37
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…

I'd say for the 0-day exploit to affect services like CloudFlare someone would need to run the exploit first on their V8 infrastructure instances. This would require ahead knowledge of the vulnerability and someone either within CloudFlare or at one of it's used code dependencies to plant malicious code. Since a rolling upgrade seems to be fully automated at CloudFlare and can be done within a few hours for the compl…

You don’t need to know anyone at Cloudflare to run the exploit on their v8 infrastructure... you just need to sign up here: https://workers.cloudflare.com/

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

#38
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…

Thanks; FWIW, I'd definitely read that blog post, and watched the talk you gave a while back (paying careful attention to the Q&A, etc. ;P). (I had had a back/forth with you a while back, actually, surrounding how you limit the memory usage of workers, and in the end sam still unsure what strategy you went with.)

https://news.ycombinator.com/item?id=23975152

BTW: if there is any hope you can help put me in touch with people at Cloudflare who work on the Ethereum Gateway, I would be super grateful (I wanted to use it a lot--as I had an "all in on Cloudflare" strategy to help circumvent censorship--but then ran into a log of issues and am not at all sure how to file them... a new one just cropped up yesterday, wherein it is incorrectly parsing JSON/RPC id fields). On the off chance you are interested in helping me with such a contact (and I appreciate if you aren't; no need to even respond or apologize ;P): I am saurik@saurik.com and I am in charge of technology for Orchid.

Post reply on HN