Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


All major distros are using wayland these days.


Along with like 1 in 5 users.


Ubuntu 22.04 now defaults to Wayland so that should make a big difference in the coming years


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.


Please stop using "nix" to mean Unix and similar systems. *nix is OK. There is an important package manager named Nix.


None of those other apps are constantly running code written by millions of different people many of which are actively attacking you possibly right now in one tab while you are typing in the other.

It has to make a Herculean effort because it is by far the worst possible app to be typing $SensitiveMessage in.

At least Kate or gedit probably doesn't have a second tab open running a JavaScript subprocess which is presently trying to attack you so it can cryptolocker you or empty your wallet.


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


Chromium and dreivatives had this for years. Firefox's isolation is making progress, but it has a ways to go before it matches Chromium.

FF devs are finalizing a utility process overhaul and laying the groundwork for CFI; for years, Chromium has had both with a much more thorough implementation than FF will in the near future. However, the browser space desperately needs competition so I'll take what I can get. Sigh.


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


The syscalls necessary to do so are blocked by seccomp-bpf.


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.


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.


Neither of these things are possible in a sandboxed browser: the syscalls are blocked, and the filesystem isn't (fully) accessible.


What is the mechanism for this kind of sandboxing?


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.


Looks cool, I clearly haven’t kept up with this.


Google [seccomp bpf].


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.


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.


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.


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.


That sounds like more work than "ssh with one extra flag"


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.


So it's like mosh for X forwarding?


Yeah, I think the project describes itself as "screen for X" or something like that.


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


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


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.


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.


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.


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.


> It's hard to overstate how much of a benefit this is in terms of security for those on Linux.

I assumed you talked about "those on Linux", not "those on Linux who have non-negligible probability of being targeted by hostile nation-states".

It's often difficult to step back and re-evaluate initial claims, and we sometimes choose to use tactics like zooming in on improbable contexts to justify them. But I think it's healthy to face criticism that may snap us out of it, so I'm writing this comment. But it's late now, so I will not be able to follow up anymore.

P.S. I don't have GNOME installed :)


Nation states aren't the only threat. There are billion dollar organized crime and fraud networks that have the means to both collect, and successfully weaponize, such RCEs.


It's been a bit since I've looked, but browser RCEs are particularly expensive and coveted. They're a potential vector for 1-click soft/hard roots in homebrew and hacking communities, and of course, 1-click RCEs are invaluable to anyone who has the resources to obtain them and victims to exploit.


I take this to mean that you think they are rare, confirming a part of my assessment on the probability of risk.

Since I cannot reply to your other comment, I will respond here. What proportion of Firefox-Linux users do you think are victims of such RCE attacks?


They are definitely rare, but once they exist they can spread like wildfire because people (usually correctly) trust browsers to sandbox websites. Put another way, browsers run untrusted programs day in and day out on virtually all sorts of otherwise trusted devices (including enterprise devices) so the impact is gigantic.


Good point, why even bother pushing out patches?


Isn't it a better idea to simply use Wayland?


The best idea would be to use Wayland in addition to these new Firefox process isolation features. That provides multiple layers of defense against possible sandbox escapes and exploitable bugs in the Wayland server.


Wat

I don't think you actually understand what's going on here.

The untrusted programs in this case would be javascript and other exploitable things that firefox interprets every time you visit a webpage. Unless you run firefox itself under a different UID or inside of a VM you are effected by this, regardless of whether you are running other "untrusted" software or not.

Maybe you are thinking that using X11 as an attack vector requires a "bad" program running in addition to firefox? If so, that is not the case, any program that is running on X11 that can execute commands or read and write files could be used for this purpose. A terminal emulator is a pretty good example of such a program.


Even if firefox was running under a different UID, they would still have to grant it access to the X server via xhost/xauth or whatever.

They have certainly misunderstood the attack. Claiming this has zero utility is effectively saying sandboxing is useless, which is just plain wrong.

Congratulations to Mozilla for getting this shipped!


Well, end user, all your files may be held for crypto ransom, but at least the machine is untouched! Very High Security!


>If such a user wants to run untrusted programs, he'd use a virtual machine anyway.

In your imaginary world. Real users don't know what a VM is and expect their system to be able to run untrusted programs without exposing all of their data. Which they are able to do on most modern systems.


We are talking about users of the Linux operating system. Many of them do know what a VM is. If they don't, or if they expect to be able to run untrusted programs willy nilly, then the benefit of Firefox doing this is, again, basically zero.

As I cannot reply to your reply, I will write the response here. By using Wayland, surely the direct benefit of this change to you is zero...


I use Linux and I don't audit the source and dependencies of every single program I use or run things in VMs. I do expect wherever possible that programs run in a sandbox with the most limited set of permissions. I have been running almost everything in Flatpak on Wayland and it seems to clearly be the future.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: