4 ms·

I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module. All interaction between a Native Client module,

I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module. All interaction between a Native Client module, the host process, and the host the operating system must be mediated via the PPAPI (Pepper API). Native Client has a set of rules which are enforced via the validator to ensure that untrusted code (that is Adobe Flash itself) cannot jump, load or store outside to addresses outside the sandbox. More information on how Native Client does this can be found in the links below. Note: you should be familiar with the x86 and x86-64 instruction set for it to make much sense. Nevertheless, here is some more information: [1] https://support.google.com/chrome/answer/108086?hl=en-GB https://support.google.com/chrome/answer/108086?hl=en-GB [2] http://www.eecs.harvard.edu/~greg/cs255sp2004/wahbe93efficient.pdf http://www.eecs.harvard.edu/~greg/cs255sp2004/wahbe93efficie... [3] http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf http://static.googleusercontent.com/media/research.google.co... [4] http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35649.pdf http://static.googleusercontent.com/media/research.google.co...

justizin 11y ago
> I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module. That is, indeed, smart, but I stopped using Chrome on the basis that I don't want to use a browser that is developed by a company whose customers are advertises and for whom I am the product. :/ I was an early Chrome adopted and I saw the tide turning a way I didn't like. I've actually been pretty happy with Safari and ClickToFlash plugin of late, I'm not as worried about sandboxing it when I only use it in a couple of places behind AdBlockPlus.
- georgerobinson 11y ago
  I don't use Chrome either. I like Firefox - even if it is less secure (in principle) than Chrome (no process separation between domains or sandboxing of plugins). The reason Native Client exists extends well beyond Adobe Flash Player. Native Client exists to enable your browser to run native code from any website (think compiled C and C++ code) without it being able to compromise the security of your machine.
scurvy 11y ago
Exploits have broken out of the sandbox before using OS-level security holes. The sandbox is not anywhere near 100% effective. If you feel safe using Flash in Chrome because of the sandbox, you might want to re-evaluate.
- georgerobinson 11y ago
  Can you expand as that? Did they break out via the service runtime, or through an implementation defect in the validator? I recall that Chris Rohlf presented an implementation defect in one of the two at a Black Hat conference some years back, but the sandboxing is otherwise solid.
  - scurvy 11y ago
    They don't go into detail, but Google confirms you can break out of the sandbox by coupling a Flash exploit with an OS exploit. http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-teams-flash-zero-day/ http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-te...
justinschuh 11y ago
Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features. It absolutely does not use a strict PPAPI sandbox and does not run under NaCl. To explain some differences, the Flash plugin is not bound to Web origins like NaCl plugins are, because Flash cannot strictly follow the Web origin model. And there are platform differences as well, such as on Windows where Flash requires GDI access but for other sandboxed content we block the entire win32k subsystem (including GDI). My advice for security conscious people is to enable click-to-play in Chrome for Flash content, because it has a featureset and legacy dependencies that prevent it from ever being sandboxed as strongly as other content.
- georgerobinson 11y ago
  > Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features Thanks for the authoritative reply! If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI? Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI? If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome? Finally, can you comment on this quote from http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-teams-flash-zero-day/ http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-te...: > Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect?
  - justinschuh 11y ago
    > If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI? I think you might have a few misconceptions. Chrome employs an outer process sandbox using OS primitives like seccomp-bpf on Linux and token restrictions on Windows. This process level sandboxing is what we use for running all untrusted content in Chrome. NaCl runs inside this outer sandbox as well, but it also applies an inner sandbox enforcing code flow integrity by verifying binaries against a subset of allowed instructions. PPAPI provides a portability layer that also serves to broker access to resources for any of Chrome's sandboxing mechanisms. So, something like PPAPI is needed for any sandboxed Chrome code, regardless of the sandboxing mechanism. > Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI? PPAPI isn't a security layer. As I mentioned above, it's a portability layer that can be used to broker resource access to sandboxed code. And PPAPI Flash is definitely sandboxed; it's just in a process sandbox that doesn't have the additional restrictions of NaCl's CFI sandbox. To explain a bit more, sandboxing in general isn't a binary state. Rather, there are varying degrees of restrictions that can be employed depending on the content, and in the case of Flash there are certain implementation details and legacy requirements that prevent it from running under the full set of restrictions that Chrome can apply to other content. > If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome? No, as I mentioned above Flash is sandboxed and runs at a severely reduced privilege. However, depending on the platform Flash may run at slightly greater privilege than Chrome runs e.g. Web content. And on all platforms, the Flash sandbox is less restrictive than the NaCl CFI sandbox (mostly due to the absence of CFI, but there are a few other differences as well). >> Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology > It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect? The Hacking Team leaks included a Windows kernel escalation exploit against font parsing code exposed by Windows GDI. The vulnerability has since been fixed by Microsoft, but it was previously exposed to any process that could access GDI, which includes Flash in Chrome (and every other browser for that matter). This also highlights the point I made earlier about varying degrees of sandboxing on different platforms, because Chrome doesn't expose GDI to Web content. Rather, Chrome uses a capability present in Windows 8 and above to disconnect the win32k subsystem from sandboxed Web processes, shutting off GDI and all other Win32 attack surface entirely. However, the same approach is not viable for Flash because the Windows version of Flash is coupled very tightly with GDI.

justizin 11y ago

> I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module. That is, indeed, smart, but I stopped using Chrome on the basis that I don't want to use a browser that is developed by a company whose customers are advertises and for whom I am the product. :/ I was an early Chrome adopted and I saw the tide turning a way I didn't like. I've actually been pretty happy with Safari and ClickToFlash plugin of late, I'm not as worried about sandboxing it when I only use it in a couple of places behind AdBlockPlus.

georgerobinson 11y ago
I don't use Chrome either. I like Firefox - even if it is less secure (in principle) than Chrome (no process separation between domains or sandboxing of plugins). The reason Native Client exists extends well beyond Adobe Flash Player. Native Client exists to enable your browser to run native code from any website (think compiled C and C++ code) without it being able to compromise the security of your machine.

scurvy 11y ago

Exploits have broken out of the sandbox before using OS-level security holes. The sandbox is not anywhere near 100% effective. If you feel safe using Flash in Chrome because of the sandbox, you might want to re-evaluate.

georgerobinson 11y ago
Can you expand as that? Did they break out via the service runtime, or through an implementation defect in the validator? I recall that Chris Rohlf presented an implementation defect in one of the two at a Black Hat conference some years back, but the sandboxing is otherwise solid.
- scurvy 11y ago
  They don't go into detail, but Google confirms you can break out of the sandbox by coupling a Flash exploit with an OS exploit. http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-teams-flash-zero-day/ http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-te...

justinschuh 11y ago

Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features. It absolutely does not use a strict PPAPI sandbox and does not run under NaCl. To explain some differences, the Flash plugin is not bound to Web origins like NaCl plugins are, because Flash cannot strictly follow the Web origin model. And there are platform differences as well, such as on Windows where Flash requires GDI access but for other sandboxed content we block the entire win32k subsystem (including GDI). My advice for security conscious people is to enable click-to-play in Chrome for Flash content, because it has a featureset and legacy dependencies that prevent it from ever being sandboxed as strongly as other content.

georgerobinson 11y ago
> Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features Thanks for the authoritative reply! If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI? Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI? If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome? Finally, can you comment on this quote from http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-teams-flash-zero-day/ http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-te...: > Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect?
- justinschuh 11y ago
  > If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI? I think you might have a few misconceptions. Chrome employs an outer process sandbox using OS primitives like seccomp-bpf on Linux and token restrictions on Windows. This process level sandboxing is what we use for running all untrusted content in Chrome. NaCl runs inside this outer sandbox as well, but it also applies an inner sandbox enforcing code flow integrity by verifying binaries against a subset of allowed instructions. PPAPI provides a portability layer that also serves to broker access to resources for any of Chrome's sandboxing mechanisms. So, something like PPAPI is needed for any sandboxed Chrome code, regardless of the sandboxing mechanism. > Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI? PPAPI isn't a security layer. As I mentioned above, it's a portability layer that can be used to broker resource access to sandboxed code. And PPAPI Flash is definitely sandboxed; it's just in a process sandbox that doesn't have the additional restrictions of NaCl's CFI sandbox. To explain a bit more, sandboxing in general isn't a binary state. Rather, there are varying degrees of restrictions that can be employed depending on the content, and in the case of Flash there are certain implementation details and legacy requirements that prevent it from running under the full set of restrictions that Chrome can apply to other content. > If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome? No, as I mentioned above Flash is sandboxed and runs at a severely reduced privilege. However, depending on the platform Flash may run at slightly greater privilege than Chrome runs e.g. Web content. And on all platforms, the Flash sandbox is less restrictive than the NaCl CFI sandbox (mostly due to the absence of CFI, but there are a few other differences as well). >> Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology > It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect? The Hacking Team leaks included a Windows kernel escalation exploit against font parsing code exposed by Windows GDI. The vulnerability has since been fixed by Microsoft, but it was previously exposed to any process that could access GDI, which includes Flash in Chrome (and every other browser for that matter). This also highlights the point I made earlier about varying degrees of sandboxing on different platforms, because Chrome doesn't expose GDI to Web content. Rather, Chrome uses a capability present in Windows 8 and above to disconnect the win32k subsystem from sandboxed Web processes, shutting off GDI and all other Win32 attack surface entirely. However, the same approach is not viable for Flash because the Windows version of Flash is coupled very tightly with GDI.