If it's got a fix it's not a zero-day.
Chrome zero-day released on GitHub – fixed on V8 but still works on latest
111–120 of 160 posts
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#112Earlier 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…
> 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 progress now. It will…
My guess is that the main feature which enables this kind of automation is that they can take down any node without consequences. So they can just install an update on all the machines, and then reboot/restart the software on the machines sequentially. If you have implemented redundancy correctly, then software updating becomes simple.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#113Earlier quoted context omitted.
Can you include me too?! I wish I could automate the hell like they do :P
You can!
Specifically you can do two things: 1) planned incremental improvements, 2) simpler designs.
For 1), write down the entire manual workflow. Start automating pieces that are easy to automate, even if someone has to run the automation manually. Continue to automate the in-between/manual pieces. For this you can use autonomation to fall back to manual work if complete automation is too difficult/risky.
For 2), look at your system's design. See where the design/tools/implementation/etc limit the ability to easily automate. To replace a given workflow section, you can a) replace some part of your system with a functionally-equivalent but easier to automate solution, or b) embed some new functionality/logic into that section of the system that extends and slightly abstracts the functionality, so that you can later easily replace the old system with a simpler one.
To get extra time/resources to spend on the automation, you can do a cost-benefit analysis. Record the manual processes' impact for a month, and compare this to an automated solution scaled out to 12-36 months (and the cost to automate it). Also include "costs" like time to market for deliverables and quality improvements. Business people really like charts, graphs, and cost saving estimates.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#114Do not casually browse the web with JavaScript enabled. The idea of trustless secure computing is compelling but it’s ultimately not reality. There is a new browser engine rce vulnerability on a regular basis, whether it’s chrome or mobilesafari
Or, you know, simply do whatever you want in a VM.
You cannot browse through a VM locally on iOS.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#115Earlier quoted context omitted.
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).
Hey I'm the exploit author, just run "chrome.exe --no-sandbox exploit.html" it will work.
What is your motivation of putting it on github? Have you considered selling it to google?
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#116Ah 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.
Yeah, today’s browsers remind me of flash and acrobat: they add features faster than they can fix security bugs. And those features are default on for everyone to exploit. Yeah, I know the comparison is a hyperbole.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#117Earlier quoted context omitted.
Yeah. And it's not even bugs in the Wasm engine that are the problem; the RWX memory for Wasm JIT code makes all other bugs into potential RCE bugs. It must be banished! :)
Having worked in other spaces ensuring W^X on the basis that there is no good reason for it, the only exception is usually "because I need to code generate". How do you even go about getting rid of WRX in a JIT? Do you generate and then remove W?
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.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#118So what does it do? https://github.com/r4j0x00/exploits/blob/7ba55e5ab034d058774...
I ran both the exploits[0][1] on Chrome (89.0.4389.114) on Windows and got AW SNAP: Access violation on both. I then straced the tab processes on Debian (as best as I could guess which chrome child processes were tabs via top activity as I loaded stuff in them) and ran the exploit. Nothing seemed unusual. Just all the system calls stopped after the exploit was run, and the tab crashed. I guess it would be good to gdb…
As others have mentioned, this doesn't have a sandbox escape so you need to run with --no-sandbox for the exploit to work
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#119So what does it do? https://github.com/r4j0x00/exploits/blob/7ba55e5ab034d058774...
Broadly speaking, the wasm stuff is only there as a method of getting the browser to execute shellcode, its a pretty standard lump of code for turning a memory bug into code execution in v8. What this shellcode does is open calculator when the browser's sandbox is disabled (`--no-sandbox`). In general in v8 exploitation, once you've reached a point where you can read and write arbitrary memory, you find that v8 will…
> In general in v8 exploitation, once you've reached a point where you can read and write arbitrary memory, you find that v8 will only create either RW or RX pages for you when the JIT compilation happens. WASM is a neat little trick for getting a handle to a RWX page.
It's not a neat trick, but a grave problem of WASM model.
WASM memory (in)security will be a big problem until all of memory security tricks from native code will be migrated to WASM world, and then there will be not much use of WASM anymore.
Re: Chrome zero-day released on GitHub – fixed on V8 but still works on latest
#120Earlier quoted context omitted.
Having worked in other spaces ensuring W^X on the basis that there is no good reason for it, the only exception is usually "because I need to code generate". How do you even go about getting rid of WRX in a JIT? Do you generate and then remove W?
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.