> 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.
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.
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.
So it's only more secure if you think emacs / xterm / your text editor is real likely to be compromised
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.
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.
You can even run Firefox via Wayland and forward a persistent XWayland session if that's your cup of tea.
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.
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.
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.
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.
if you believe those numbers... 64% vs 3% market share. of course something that impacts 64% of the internet will be more valuable.
/s
In general my recollection is that Chrome splits up more of its components. It sounds like, based on this post, the gpu process is now separated and there's sandboxing efforts going into that, but I'm pretty sure Chrome has had that for years now.
The current mitigations seem to be doubling-down on getting rid of C++ memory safety errors (still the main source of security holes), with Mozilla pulling the Rust and WebAssembly card. So there's some divergence here, rather than parallel paths with one ahead.
I don't know much about the specifics of the implementations, but that seems like a significant difference for such a crucial security feature, especially post meltdown/spectre.
(You mentioned site isolation, which is a different feature, but the dates you have look right for that.)
If you have a newer kernel (5.13 or greater), you may like to experiment with landlock. It's pretty cool and unlike FireJail, no suid required. Here's a landlock wrapper for Firefox:
https://github.com/62726164/misc/blob/main/go/landlock/firef...
I'd like to learn more about open source/free Windows and MacOS MAC tools. If you know of any, please post about your experience with them.
Edit: This Windows functionality seems similar to seccomp and pledge: https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-...
Maybe one day we'll have web browsers that don't have any C code. Nothing against C. It's a great systems language, but I'd rather my web browser not use it.
Browsing the web is probably the most dangerous thing the average computer user does.
I guess that makes sense, but you'd have to be aware of it when uploading and downloading stuff (it would only work from a specific designated folder).
This is what macOS enforces - apps live within their containers.
I wonder if there was an alternative specifically for the scrollbar here - some way of obtaining an outer "shell" (via win32k, but then basically "orphaning" it so that you can't do anything besides kill it when you're finished) that just provides the window with an empty scrollable element that is then populated by the restricted process.
That ship has really sailed though; I think the days of native widgets are quickly coming to an end.
When you write a Windows program, you call APIs from User32.dll, GDI32.dll, and Kernel32.dll. Those are the user mode libraries, and the main entry point to call the Windows API functions.
What's actually inside of those? User32 and GDI32 are pretty much stubs. Mostly, they have a small amount of code, then proceed to call functions in Win32U.dll. Then Win32U.dll makes system calls, causing Win32k (Kernel Mode) to carry out the functions. So everything from BeginPaint to GetWindowText is going to be a system call that's placed from within Win32U, then handled by Win32K.
Meanwhile, Kernel32.dll is a user-mode library (despite the name being "kernel32"), which mostly makes calls to NTDLL.dll. Then NTDLL makes system calls that get handled by kernel-mode components.
The isolation thing that Mozilla is using here does not stop the NTDLL system calls that Kernel32.dll uses, just the calls to Win32U/Win32K (GDI32.dll and User32.dll). So there needs to be other mitigation methods in place for the Kernel32/NTDLL stuff, such as reduced user privileges.
But preventing all the Win32U/Win32K stuff from being called does greatly reduce the attack surface.
I can think of several things you could do to Kernel32 to try to lock it down:
* Patch out all the entry points of Kernel32 you don't want to be used. Then patch out their corresponding entry points out of NTDLL. Then remove the code that invokes the system calls inside of NTDLL. Yes, you can just simply overwrite user mode code willy-nilly as long as you have write access to the process memory.
(Regular programs use the entry points. Someone trying to do something fancy might skip the entry points. If your hackers are using things like ROP chains and gadgets, chances are they don't care about entry points.)
* Create some kind of NT security context so that nothing interesting works anymore. I don't know how this works, but many NT functions want a security context passed in.
* When you are executing code, and you have no idea where Kernel32 is, you can read the module list out of the TEB, and that finds you Kernel32 and NTDLL. Maybe something that could thwart that, but not break code.
In the end though, what could stop the process from attempting to SYSENTER from somewhere besides NTDLL?
