The multiprocess architecture in IE8 isn't an isolation layer as the browser can and does frequently render multiple tabs under the same process. It's not uncommon to hear reports of 40 processes for 2 tabs or 40 tabs for 2 processes.
When you contrast it with Chrome which uses basically every single operating system mitigation in addition to their sandboxing and the difference really is striking.
I'm looking forward to the future of e10s Firefox since it now enables them to move forward with more advanced security mitigations and better defense in depth. I believe Mozilla released a plan for the future of these things which it showed what they wanted to do step by step (e.g. plugins first, etc).
Exactly this.
People's hate of Mozilla is very similar and as misguided as their hate for Microsoft and it really shows in your original statement that they can do no right.
Instead of a congratulatory "welcome to the club (of one)", it's "why weren't you a member all along?"
https://github.com/WebKit/webkit/blob/master/Source/WebKit2/...
For IPC they use something custom (part of the WebKit repo) called "CoreIPC".
I believe most Chromium based browsers could also fall under that category although I admit that's just being pedantic.
Furthermore at least Edge and to the lesser extent IE(11) do have some sandboxing which purpose is to enhance security. Their (renderer) processes do run at a low integrity level and are ran within an Appcontainer. On IE11 this is enabled through the use of Enhanced protected mode with 64-bit processes. This allows it to use AppContainers even with the desktop browser. Edge always uses AppContainers AFAIK.
I'm not sure it's sandboxed to the same extent as Chrome but it is a level of defense in depth. Edge also uses some security mitigations that Chrome does not such as CFG (control flow guard) although that's not dependent on a sandbox so CFG, baring performance issues, could be used in any browser sandboxed or not.
Flash and Media Plugins (video decoders, EME/DRM) have already been sandboxed for several releases. There is a content sandbox in the development versions of Firefox. Of course it won't ship before e10s is considered stable, because that's a hard prerequisite for it. The amount of protection also varies by operating system (Windows and Mac OS X are pretty OK, Linux is still pretty crappy) but obviously that is improving week by week.
Firefox provides its own sandboxing now? Flash used to use a subset of the Chrome sandbox for Flash but that was restricted to the 32-bit version of the browser. As far as I was aware Firefox just ran it in the plugin-container processes for crash protection and nothing else (if protected mode wasn't being used or if you were on 64-bit Firefox). Does Firefox now make use of OS mitigations and integrity levels for sandboxing the plugin process?
Here is the Firefox bug tracking the 64-bit sandbox work:
That hasn't been true for at least 5 years. Safari has used a sandboxed, multi-process architecture for Web content since version 5.1.
I was referring to the internal sandboxing Safari does to isolate plugins from everything else.
Web content and plug-in processes are XPC services, yes.
Chrome for example doesn't even let render processes touch OpenGL. All the rendering and layout logic for the page is computed in a separate process, and draw commands are sent over a IPC pipe instead to a controlled renderer, which actually issues draw commands to the GPU. (If my memory is still correct, anyway). Given the complex layout and rendering engines in browsers, this is good to have - they're almost purely computational logic, so they don't need many capabilities like "Open File" or "Spawn Process". It's sort of a forced realization of real capability based security, like Eros or Capsicum.
Getting outright code execution (calc.exe) is only useful once you also have a way to escape the sandbox, after you've got code execution in the process you exploited. And on (all?) OSs, this is enforced pretty much by the kernel and many other things. So you need a kernel exploit, with a viable triggering mechanism from within the sandbox, on top of the browser exploit if you actually want to break out further.
In contrast, in Firefox, etc, once you've exploited the singular process rendering your page, you have full access to the whole system, at the privilege level of the application. There are no restrictions on what your payload can do, so spawning calc.exe is trivial. This is also why multi-process is a necessary, but not sufficient, part of a sandboxed design. Firefox still has a huge, huge amount of ground to cover to catch up to Chrome, even once it's gone full multi-process.
That said, none of these attacks are impossible, even with Chrome. They only mitigate/ban certain exploit mechanisms as a consequence of design, making things much harder, but fundamentally you can still get by. With a few infoleaks and one or two good bugs, you can take the cake. And, purely by the fact these projects are so large, those things exist. But Chrome has a much higher barrier to full compromise, I'd say, and it had the advantage of being designed that way from the start.
The next step is to do things like enforce very fine-grained control flow integrity over the whole browser, which will help stop code-reuse attacks (e.g. ROP/JOP), thus killing a whole class of exploitation mechanisms outright. grsecurity's RAP work has already been tested on the whole of the Chromium code base, and has excellent performance in general. Hopefully in time something similar can come to a wider audience.
Except on Android, where I believe it does in fact let them do that.
[1] https://cs.chromium.org/chromium/src/content/renderer/render...
The hard part that took this long has been updating the browser UI to not directly poke at the web content (which is now in a different process) and not breaking all the extensions which like to do that sort of thing too badly.
How about airgap every website you visit by buying a new computer?
I hope there's an invisible ;) in there somewhere.
My advice used to be "run it as its own user"