6 ms·

It's ridiculous that they still don't have sandboxing years after Chrome, Safari, and IE shipped it. It's just negligent as a browser developer to not have that

It's ridiculous that they still don't have sandboxing years after Chrome, Safari, and IE shipped it. It's just negligent as a browser developer to not have that basic measure of security in place.

nickpsecurity 10y ago
It was common for security-savvy users of Firefox to combine it with third-party solutions like SandboxIE, DefenseWall, and AppGuard. Later browser VMs. A sandbox plus NoScript, Flasblock, Adblock, etc actually made it a stronger option than competitors that were just sandboxing renderers, JS, and do on.
bioneuralnet 10y ago
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.
cptskippy 10y ago
I don't think you understand what you're complaining about. Each browser has had different types of sandboxing. IE's approach is to run the whole process (just the one) in PE mode. Chrome goes a step further and sandboxes each tab to its own process. Safari just sandboxes plugins. Firefox, prior to Electrolysis, sandboxes JavaScript, Media Playback containers, and Plugins. Post Electrolysis it does processes as well.
- ygra 10y ago
  IE does process isolation too since IE 8, not just relying on low-integrity mode for a single process.
  - cptskippy 10y ago
    The IE process has run in protected mode since IE7. In 10 they introduced enhanced protection mode and AppContainer sandboxing. 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.
- ryuuchin 10y ago
  It's the lack of defense in depth which I would say is disappointing more than anything. Firefox prior to e10s pretty much ran everything save for NPAPI plugins in the same process. Perhaps it is "sandboxed" in the code but in practice I'm not sure you could call it a sandbox from the defense in depth standpoint. Simply running stuff in a separate process doesn't count for much if the separate process is not restricted in any way. 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).
  - 10y ago
SixSigma 10y ago
Use a VM and sandbox it yourself
- HelloImDumb 10y ago
  Roll your own android? What a stupid statement. How about airgap every website you visit by buying a new computer? I hope there's an invisible ;) in there somewhere.
  - SixSigma 10y ago
    A bit of a ;) My advice used to be "run it as its own user"

It's ridiculous that they still don't have sandboxing years after Chrome, Safari, and IE shipped it. It's just negligent as a browser developer to not have that basic measure of security in place.

nickpsecurity 10y ago

It was common for security-savvy users of Firefox to combine it with third-party solutions like SandboxIE, DefenseWall, and AppGuard. Later browser VMs. A sandbox plus NoScript, Flasblock, Adblock, etc actually made it a stronger option than competitors that were just sandboxing renderers, JS, and do on.

bioneuralnet 10y ago

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.

cptskippy 10y ago

I don't think you understand what you're complaining about. Each browser has had different types of sandboxing. IE's approach is to run the whole process (just the one) in PE mode. Chrome goes a step further and sandboxes each tab to its own process. Safari just sandboxes plugins. Firefox, prior to Electrolysis, sandboxes JavaScript, Media Playback containers, and Plugins. Post Electrolysis it does processes as well.

ygra 10y ago
IE does process isolation too since IE 8, not just relying on low-integrity mode for a single process.
- cptskippy 10y ago
  The IE process has run in protected mode since IE7. In 10 they introduced enhanced protection mode and AppContainer sandboxing. 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.
ryuuchin 10y ago
It's the lack of defense in depth which I would say is disappointing more than anything. Firefox prior to e10s pretty much ran everything save for NPAPI plugins in the same process. Perhaps it is "sandboxed" in the code but in practice I'm not sure you could call it a sandbox from the defense in depth standpoint. Simply running stuff in a separate process doesn't count for much if the separate process is not restricted in any way. 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).
- 10y ago

SixSigma 10y ago

Use a VM and sandbox it yourself

HelloImDumb 10y ago
Roll your own android? What a stupid statement. How about airgap every website you visit by buying a new computer? I hope there's an invisible ;) in there somewhere.
- SixSigma 10y ago
  A bit of a ;) My advice used to be "run it as its own user"