5 ms·

It's certainly unfortunate, but "ridiculous" is a bit much. It's just a fact of history. FF is based on a very old codebase, before sandboxing and multi-process

It's certainly unfortunate, but "ridiculous" is a bit much. It's just a fact of history. FF is based on a very old codebase, before sandboxing and multi-process arch. was a thing in browsers. Chrome is much younger, and was designed with those features in mind. And while IE is also an old codebase, MS can devote far more resources to making these complex changes than can Mozilla.

ivoras 10y ago
Are there any studies which show process sandboxing to improve security in practice?
- aseipp 10y ago
  I'm not sure about any studies, only my own observations and attempts at breaking browsers. It depends on how the sandbox is actually constructed, and what information/level of control the attacker is attempting to obtain. But, if we go by "Being able to spawn calc.exe on someone's computer" -- if you simply look at the amount of effort needed to attack a program like Chrome versus Firefox and successfully break out of the sandbox - yes, when done correctly, it adds a good layer of defense in depth. 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.
  - bzbarsky 10y ago
    > Chrome for example doesn't even let render processes touch OpenGL. Except on Android, where I believe it does in fact let them do that.
    - sunnyps 10y ago
      No, not even on Android[1]. What was different before was that there wasn't a separate GPU process but OpenGL was executed in the browser process (in process command buffer). In any case the renderer hasn't been working with GL directly on all platforms (outside of tests) for at least a few years now. [1] https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=1470179849&l=1902 https://cs.chromium.org/chromium/src/content/renderer/render...
      - bzbarsky 10y ago
        Ah, I stand corrected.
dblohm7 10y ago
This. Greenfield development makes it far easier to implement multiprocess and sandboxing. Try contending with a decade-old extension ecosystem and a legacy extension API that provides direct access to browser internals.
anthk 10y ago
Chrome took code from Webkit, and Webkit itself is from the Konqueror browser/Kpart from the KDE guys for Linux/Unix.
- HelloImDumb 10y ago
  Yep, Webkit dates to 1998, and Firefox (2002) was such a radical departure from Mozilla suite it's more than a little ridiculous in 2016 to handwave Chrome (2008)'s advantages as "greenfield." Microsoft just released a brand spanking new browser. Firefox is a great product but it's deficiencies are its deficiencies.
  - dblohm7 10y ago
    Chrome didn't have extensions when it came out. Neither did Edge.
- bzbarsky 10y ago
  The rendering engine is not the part that makes it hard to do multiprocess Firefox. Gecko has had the ability to do multiprocess stuff for years; all the stuff on the b2g process was multiprocess Gecko. 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.

ivoras 10y ago

Are there any studies which show process sandboxing to improve security in practice?

aseipp 10y ago
I'm not sure about any studies, only my own observations and attempts at breaking browsers. It depends on how the sandbox is actually constructed, and what information/level of control the attacker is attempting to obtain. But, if we go by "Being able to spawn calc.exe on someone's computer" -- if you simply look at the amount of effort needed to attack a program like Chrome versus Firefox and successfully break out of the sandbox - yes, when done correctly, it adds a good layer of defense in depth. 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.
- bzbarsky 10y ago
  > Chrome for example doesn't even let render processes touch OpenGL. Except on Android, where I believe it does in fact let them do that.
  - sunnyps 10y ago
    No, not even on Android[1]. What was different before was that there wasn't a separate GPU process but OpenGL was executed in the browser process (in process command buffer). In any case the renderer hasn't been working with GL directly on all platforms (outside of tests) for at least a few years now. [1] https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=1470179849&l=1902 https://cs.chromium.org/chromium/src/content/renderer/render...
    - bzbarsky 10y ago
      Ah, I stand corrected.

dblohm7 10y ago

This. Greenfield development makes it far easier to implement multiprocess and sandboxing. Try contending with a decade-old extension ecosystem and a legacy extension API that provides direct access to browser internals.

anthk 10y ago

Chrome took code from Webkit, and Webkit itself is from the Konqueror browser/Kpart from the KDE guys for Linux/Unix.

HelloImDumb 10y ago
Yep, Webkit dates to 1998, and Firefox (2002) was such a radical departure from Mozilla suite it's more than a little ridiculous in 2016 to handwave Chrome (2008)'s advantages as "greenfield." Microsoft just released a brand spanking new browser. Firefox is a great product but it's deficiencies are its deficiencies.
- dblohm7 10y ago
  Chrome didn't have extensions when it came out. Neither did Edge.
bzbarsky 10y ago
The rendering engine is not the part that makes it hard to do multiprocess Firefox. Gecko has had the ability to do multiprocess stuff for years; all the stuff on the b2g process was multiprocess Gecko. 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.