> 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.