4 ms·

There are two different possible attack vectors. 1. First, once you "local root" within the sandboxed process what can you compromise? a. Can the session cook

There are two different possible attack vectors. 1. First, once you "local root" within the sandboxed process what can you compromise? a. Can the session cookies be stolen? (Think gmail inline attachment rendering a malicious webp image). b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on. 2. Second, can you probe for vulnerabilities in OS sandboxing that chrome depends on to break out of sandbox? On older unpatched OS versions this is definitely possible. These attack vectors may have been fixed in newer patches of OS already so you won't see a new CVE and patch for the same from the OS vendors.

nomel 3y ago
Im not in security. What are the answers for 1a and b? Are they hypothetical? I assume no. 2, as they mentioned, is the separate CVE they suggested.
- sroussey 3y ago
  Here is a description of process and site isolation in Chrome: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md https://chromium.googlesource.com/chromium/src/+/main/docs/p...
yencabulator 3y ago
> b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on. Huh? Chrome on Linux uses a network namespace to remove all networking from the renderer process, and then uses seccomp to forbid most system calls, and can very easily prevent e.g. opening new sockets with that. https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sandboxing.md https://chromium.googlesource.com/chromiumos/docs/+/HEAD/san... https://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html https://blog.chromium.org/2012/11/a-safer-playground-for-you... https://blog.cr0.org/2012/09/introducing-chromes-next-generation.html https://blog.cr0.org/2012/09/introducing-chromes-next-genera...
yakubin 3y ago
Ad 2. You don’t need a vulnerability in OS sandboxing. You need a way to start communicating with the browser process, since the way renderer processes do I/O is they delegate it to the browser process by communicating over a socket. With a sufficiently advanced arbitrary code execution that’s possible without trying to find bugs in the kernel.

nomel 3y ago

Im not in security. What are the answers for 1a and b? Are they hypothetical? I assume no. 2, as they mentioned, is the separate CVE they suggested.

sroussey 3y ago
Here is a description of process and site isolation in Chrome: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md https://chromium.googlesource.com/chromium/src/+/main/docs/p...

yencabulator 3y ago

> b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on. Huh? Chrome on Linux uses a network namespace to remove all networking from the renderer process, and then uses seccomp to forbid most system calls, and can very easily prevent e.g. opening new sockets with that. https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sandboxing.md https://chromium.googlesource.com/chromiumos/docs/+/HEAD/san... https://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html https://blog.chromium.org/2012/11/a-safer-playground-for-you... https://blog.cr0.org/2012/09/introducing-chromes-next-generation.html https://blog.cr0.org/2012/09/introducing-chromes-next-genera...

yakubin 3y ago

Ad 2. You don’t need a vulnerability in OS sandboxing. You need a way to start communicating with the browser process, since the way renderer processes do I/O is they delegate it to the browser process by communicating over a socket. With a sufficiently advanced arbitrary code execution that’s possible without trying to find bugs in the kernel.