If it's got a fix it's not a zero-day.
The fix exists in the v8 source, but hasn't reached normal Chrome yet. Unless an org is compiling Chromium from scratch, there isn't an actual useful fix available.
121–130 of 160 posts
If it's got a fix it's not a zero-day.
The fix exists in the v8 source, but hasn't reached normal Chrome yet. Unless an org is compiling Chromium from scratch, there isn't an actual useful fix available.
Earlier quoted context omitted.
Considering that JS is JIT'd (and V8 has had JS based RCEs in the past), is there any reason to believe webasm is a significant security hole?
WebAssembly (and asm.js) add additional attack surface to V8, and multiple attacks (including this one) are not possible without that
Using WASM is the method de'jour for turning arbitrary read/write/object leak into RCE. Without WASM, the writer would have to use ROP/etc, but the primitives are still there.
Check out this discussion by a bunch of the big names in the field, including Niklas B who was on the team that originally found this bug: https://twitter.com/spoofyroot/status/1379911787282243584
Earlier quoted context omitted.
"Particularly safe" is a bit alarmist, one could make the same argument about literally anything that connects to a public network isn't particularly safe
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".
So 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…
My email is in my profile.
So WebAssembly is basically Flash in terms of security?
Earlier quoted context omitted.
Kind of a dishonest characterization - Flash was sandboxed too. WASM is simply easier to sandbox and has additional constraints that make it easier to keep code from trying to break out.
The parent was talking about how the process the WASM runtime is in is sandboxed. I could be wrong, but I don't think flash did this. I think the sandbox was more of just some limitations on the APIs you were provided.
Earlier quoted context omitted.
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?
The GitHub POC was built using the patch and regression test by a third person (who you just replied to). While it's been patched in the v8 Javascript engine, that patch has not made it to Chrome (unless you're compiling Chromium from scratch) as part of Chrome's 2 week release process.
Earlier quoted context omitted.
> 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…
Look for a company who's business model includes uptime, security and scalability. And is big enough to not outsource those parts. And in a mature market where customers can tell the difference.
I'm just so tired of the whole microservices and prima donna developer bullshit.
- PicoCTF 2021: Kit Engine, Download Horsepower and Turboflan
- Hack The Box (HTBs): RopeTwo and Modern Typer
- DownUnderCTF 2020: Is This Pwn or Web
- LineCTF: BabyChrome
So 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…