5 ms·

This is a bit buried at the bottom, but: > For Linux users, we removed the connection from content processes to the X11 Server, which stops attackers from expl

This is a bit buried at the bottom, but: > For Linux users, we removed the connection from content processes to the X11 Server, which stops attackers from exploiting the unsecured X11 protocol. It's hard to overstate how much of a benefit this is in terms of security for those on Linux. Any application with access to the X11 socket effectively has the keys to the kingdom, because it can hijack other applications, including those running at higher privileges, at will. (There have been halfhearted attempts to address this over the years, but nothing that's been effective or widely adopted.) The only real solution for desktop app security on Linux is to forbid direct access to X11 entirely, and so it's a huge deal that Firefox is now able to do this. In general, doing this sort of thing is a monumental undertaking for large applications like Firefox. Kudos to my former colleagues for pulling it off.

ntnsndr 4y ago
Is this why my Firefox window went black randomly for a few seconds today?
- Caspy7 4y ago
  In my experience, most of the time black drawing like that is associated with GPU driver issues.
enriquto 4y ago
Does this mean that I will no longer be able to ssh -X myvm firefox ? This is my way of browsing and I feel much safer than running it raw.
- Hackbraten 4y ago
  That should still work. They didn’t isolate all the Firefox processes from X11. Only the content processes are affected, i.e. the processes whose attack surface is rather massive. But the content processes are still going to deliver their finished work items to the GPU process for rendering. The GPU process retains all the rights it needs, including talking to X11.
- pcwalton 4y ago
  I don't see why you wouldn't still be able to do that. Firefox still uses X11; it's just that the content processes can't directly speak the protocol now, and must go over IPC to a more trusted process to do so.
- heavyset_go 4y ago
  Any reason you're using SSH X forwarding over something like Xpra? It also works over SSH, but lets apps persist even if the SSH connection is broken for whatever reason. You can even run Firefox via Wayland and forward a persistent XWayland session if that's your cup of tea.
  - yjftsjthsd-h 4y ago
    That sounds like more work than "ssh with one extra flag"
    - heavyset_go 4y ago
      The latter is, but that's only if you want to use Wayland. Xpra offers persistent sessions behind a single command, and uses SSH by default.
  - kzrdude 4y ago
    So it's like mosh for X forwarding?
    - heavyset_go 4y ago
      Yeah, I think the project describes itself as "screen for X" or something like that.
throwaway_58291 4y ago
In the common scenario of a single user, on a single user machine, running programs under his uid, the benefit is basically zero. If such a user wants to run untrusted programs, he'd use a virtual machine anyway. So, I think it's very easy to overstate the benefit, and your comment did just that.
- pcwalton 4y ago
  Scenario: evil.com wants to take advantage of a use-after-free in some DOM API to install a keylogger. Before X11 isolation, it can: (1) get RCE in content process; (2) send events to your GNOME Shell to open a terminal; (3) send keyboard events to the terminal to download the keylogger, start it, and add it to some config file that makes it start automatically on future logins. After X11 isolation, it will: (1) get RCE in content process; (2) get stopped because it can't send keyboard/mouse events to other applications anymore.
  - throwaway_58291 4y ago
    By the probability of this risk scenario (visit evil.com, be the victim of a successful RCE, with a particular method of privilege escalation that somehow gets all the right details to work) it sure looks to me like you overstated the expected benefit (negative loss). I do concede that our utility functions may differ, if you actually believe it and not just inflating the importance of this issue. Also I may have a bias in that I disable JavaScript by default, so the probability of such a risk is much lower. I tried to not make that assumption though, in judging the expected loss.
    - pcwalton 4y ago
      You are vastly overstating the difficulty of pivoting X11 access to complete system compromise with the "somehow gets all the right details to work" phrase. It's trivial. People have literally gotten killed because of this type of attack. Yes, hostile nation-states probably don't care enough about you personally, but there are people for whom this is a life-and-death matter. The one thing that reduces the impact of this is that it's Firefox on Linux, which is a niche browser on a niche OS, but desktop Linux Firefox is a product that Mozilla officially ships, which means that it's Mozilla's responsibility to protect its users.
trashface 4y ago
This seems like it could make Firefox one of the most secure linux desktop applications? For instance, if you are typing $SensitiveMessage, you would be far better off doing that in a firefox 100 textedit box in a browser tab, rather than an xterm, or emacs, or your desktop environments preferred text editor, or anything else. I currently use "secure keyboard" in xterm but I know that has problems.
- ReactiveJelly 4y ago
  Yeah the keystrokes still have to go to some trusted process at the top that doesn't run untrusted code. So it's only more secure if you think emacs / xterm / your text editor is real likely to be compromised
- pcwalton 4y ago
  I'm pretty sure that there's nothing preventing other apps on your desktop from listening to keystrokes that are supposed to go into Firefox, unfortunately. This is a fundamental problem with the X11 protocol and as far as I know the only real solution is to switch to Wayland.
  - kramerger 4y ago
    All major distros are using wayland these days.
    - michaelmrose 4y ago
      Along with like 1 in 5 users.
      - derkades 4y ago
        Ubuntu 22.04 now defaults to Wayland so that should make a big difference in the coming years
      - 0des 4y ago
        wayland has never been a pleasant experience for me, neither was pipewire. everything the nix community fawns over seems to be regressive bullshit that breaks my system. systemd is only just now becoming acceptable in that in the past year it hasn't fucked me too hard.
tinus_hn 4y ago
But how do they prevent an attacker from simply opening his own connection? They can just look up the keys in the other processes.
- scratcheee 4y ago
  The isolated content processes shouldn't have access to the other processes memory. There might be shared memory regions, but it seems unlikely they'd store the keys to the kingdom in shared memory.
  - tinus_hn 4y ago
    They are owned by the same user so they probably have access to everything the other processes have. And they can probably just read the access token from the environment which is accessible through the /proc filesystem.
    - rockdoe 4y ago
      Neither of these things are possible in a sandboxed browser: the syscalls are blocked, and the filesystem isn't (fully) accessible.
      - tinus_hn 4y ago
        What is the mechanism for this kind of sandboxing?
        staticassertion 4y ago
        Namespaces let you create isolated views of the file system, isolated views of processes (ex: if you are in a new pid namespace and run 'ps' you only see yourself), users, network interfaces, etc. I'm not sure what Firefox does, I believe they use the Chromium sandbox, and I'm way out of date on that. It used to do some filesystem setup like hardened chroots, but I would assume that's been supplanted by fs namespacing.

ntnsndr 4y ago

Is this why my Firefox window went black randomly for a few seconds today?

Caspy7 4y ago
In my experience, most of the time black drawing like that is associated with GPU driver issues.

enriquto 4y ago

Does this mean that I will no longer be able to ssh -X myvm firefox ? This is my way of browsing and I feel much safer than running it raw.

Hackbraten 4y ago
That should still work. They didn’t isolate all the Firefox processes from X11. Only the content processes are affected, i.e. the processes whose attack surface is rather massive. But the content processes are still going to deliver their finished work items to the GPU process for rendering. The GPU process retains all the rights it needs, including talking to X11.
pcwalton 4y ago
I don't see why you wouldn't still be able to do that. Firefox still uses X11; it's just that the content processes can't directly speak the protocol now, and must go over IPC to a more trusted process to do so.
heavyset_go 4y ago
Any reason you're using SSH X forwarding over something like Xpra? It also works over SSH, but lets apps persist even if the SSH connection is broken for whatever reason. You can even run Firefox via Wayland and forward a persistent XWayland session if that's your cup of tea.
- yjftsjthsd-h 4y ago
  That sounds like more work than "ssh with one extra flag"
  - heavyset_go 4y ago
    The latter is, but that's only if you want to use Wayland. Xpra offers persistent sessions behind a single command, and uses SSH by default.
- kzrdude 4y ago
  So it's like mosh for X forwarding?
  - heavyset_go 4y ago
    Yeah, I think the project describes itself as "screen for X" or something like that.

throwaway_58291 4y ago

In the common scenario of a single user, on a single user machine, running programs under his uid, the benefit is basically zero. If such a user wants to run untrusted programs, he'd use a virtual machine anyway. So, I think it's very easy to overstate the benefit, and your comment did just that.

pcwalton 4y ago
Scenario: evil.com wants to take advantage of a use-after-free in some DOM API to install a keylogger. Before X11 isolation, it can: (1) get RCE in content process; (2) send events to your GNOME Shell to open a terminal; (3) send keyboard events to the terminal to download the keylogger, start it, and add it to some config file that makes it start automatically on future logins. After X11 isolation, it will: (1) get RCE in content process; (2) get stopped because it can't send keyboard/mouse events to other applications anymore.
- throwaway_58291 4y ago
  By the probability of this risk scenario (visit evil.com, be the victim of a successful RCE, with a particular method of privilege escalation that somehow gets all the right details to work) it sure looks to me like you overstated the expected benefit (negative loss). I do concede that our utility functions may differ, if you actually believe it and not just inflating the importance of this issue. Also I may have a bias in that I disable JavaScript by default, so the probability of such a risk is much lower. I tried to not make that assumption though, in judging the expected loss.
  - pcwalton 4y ago
    You are vastly overstating the difficulty of pivoting X11 access to complete system compromise with the "somehow gets all the right details to work" phrase. It's trivial. People have literally gotten killed because of this type of attack. Yes, hostile nation-states probably don't care enough about you personally, but there are people for whom this is a life-and-death matter. The one thing that reduces the impact of this is that it's Firefox on Linux, which is a niche browser on a niche OS, but desktop Linux Firefox is a product that Mozilla officially ships, which means that it's Mozilla's responsibility to protect its users.

trashface 4y ago

This seems like it could make Firefox one of the most secure linux desktop applications? For instance, if you are typing $SensitiveMessage, you would be far better off doing that in a firefox 100 textedit box in a browser tab, rather than an xterm, or emacs, or your desktop environments preferred text editor, or anything else. I currently use "secure keyboard" in xterm but I know that has problems.

ReactiveJelly 4y ago
Yeah the keystrokes still have to go to some trusted process at the top that doesn't run untrusted code. So it's only more secure if you think emacs / xterm / your text editor is real likely to be compromised
pcwalton 4y ago
I'm pretty sure that there's nothing preventing other apps on your desktop from listening to keystrokes that are supposed to go into Firefox, unfortunately. This is a fundamental problem with the X11 protocol and as far as I know the only real solution is to switch to Wayland.
- kramerger 4y ago
  All major distros are using wayland these days.
  - michaelmrose 4y ago
    Along with like 1 in 5 users.
    - derkades 4y ago
      Ubuntu 22.04 now defaults to Wayland so that should make a big difference in the coming years
    - 0des 4y ago
      wayland has never been a pleasant experience for me, neither was pipewire. everything the nix community fawns over seems to be regressive bullshit that breaks my system. systemd is only just now becoming acceptable in that in the past year it hasn't fucked me too hard.

tinus_hn 4y ago

But how do they prevent an attacker from simply opening his own connection? They can just look up the keys in the other processes.

scratcheee 4y ago
The isolated content processes shouldn't have access to the other processes memory. There might be shared memory regions, but it seems unlikely they'd store the keys to the kingdom in shared memory.
- tinus_hn 4y ago
  They are owned by the same user so they probably have access to everything the other processes have. And they can probably just read the access token from the environment which is accessible through the /proc filesystem.
  - rockdoe 4y ago
    Neither of these things are possible in a sandboxed browser: the syscalls are blocked, and the filesystem isn't (fully) accessible.
    - tinus_hn 4y ago
      What is the mechanism for this kind of sandboxing?
      - staticassertion 4y ago
        Namespaces let you create isolated views of the file system, isolated views of processes (ex: if you are in a new pid namespace and run 'ps' you only see yourself), users, network interfaces, etc. I'm not sure what Firefox does, I believe they use the Chromium sandbox, and I'm way out of date on that. It used to do some filesystem setup like hardened chroots, but I would assume that's been supplanted by fs namespacing.