| ▲ | zahlman 6 hours ago | |||||||
Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox? | ||||||||
| ▲ | arcfour 5 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) | ||||||||
| ||||||||
| ▲ | insanitybit 5 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". | ||||||||
| ▲ | r_lee 6 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 | ||||||||
| ▲ | p-e-w 6 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. | ||||||||