upvote

points

by jnwatson7 hours ago |
comments
upvoteby r_lee6 hours ago|
next
[-]
I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.
reply
upvoteby ranger_danger6 hours ago|
parent|
[-]
Seems to use OS-specific kernel syscall filtering facilities.

Windows: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...

Linux: https://chromium.googlesource.com/chromium/src/+/0e94f26e8/d...

reply
upvoteby Genwald6 hours ago|
parent|
next
[-]
V8 also has its own sandbox, which I believe exists in that sandbox. I assume that's the one this exploit has RCE in, but its unclear.

https://chromium.googlesource.com/v8/v8.git/+/refs/heads/mai...

reply
upvoteby insanitybit6 hours ago|
parent|
[-]
I would assume in this case that there's full renderer control, not just a bypass of the in-process isolation.
reply
upvoteby r_lee6 hours ago|
parent|
prev|
[-]
great link, thanks
reply
upvoteby zahlman6 hours ago|
prev|
next
[-]
Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox?
reply
upvoteby arcfour5 hours ago|
parent|
next
[-]
Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.

However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.

(This is a very oversimplified explanation but I think this is the disconnect people are having)

reply
upvoteby bawolff4 hours ago|
parent|
[-]
> JavaScript in the browser has no way to even express ... "list the contents of `C:\Users\Documents` and upload all of the files"

this is besides the point, but javascript has the file system api.

anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.

reply
upvoteby insanitybit6 hours ago|
parent|
prev|
next
[-]
Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.

But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.

That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".

reply
upvoteby r_lee6 hours ago|
parent|
prev|
next
[-]
because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native

can't get a proper ios/Android RCE with just JS code exec

reply
upvoteby p-e-w6 hours ago|
parent|
prev|
[-]
It can do some things that JS can’t do, such as invalid pointer writes. But you are correct that this doesn’t automatically imply system access.
reply
upvoteby TacticalCoder6 hours ago|
prev|
[-]
> It means it can execute arbitrary machine code in the sandbox.

Well which is precisely why we have sandboxes.

To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".

More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.

A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".

reply