Firefox content process has a live connection to the X11 server.

NEW
Assigned to

Status

()

defect
P3
normal
4 years ago
6 months ago

People

(Reporter: jld, Assigned: gcp)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Trunk
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: sblc4)

Attachments

(1 attachment)

See also bug 582057 comment #13 for historical context.  We basically can't have a meaningful sandbox for content processes on X11 platforms as long as that file descriptor is there.

Chromium doesn't do this — indeed, it doesn't connect to the X11 server from the renderer process in the first place — so it is possible.  The question is how much work would be needed.
I've used conditional breakpoints to find where we're using the X11 socket, and I'm attaching a selection of stack traces.  It seems to be heavily used in layers/graphics code, and also polled for events in nsAppShell::ProcessNextNativeEvent.
Hi Milan, any idea who knows enough about our linux gfx plumbing to say what is needed here? If this is going to be a big chunk of work it would be good to know about it ahead of time!
Flags: needinfo?(milan)
Big chunk of work, but unclear it's the work that we would want to do anyway.  CC-ing Jeff, he wanted to have the conversation about "why is the sandbox meaningless if we have this connection", though we know it won't be as good a sandboxing with it.
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #3)
> CC-ing Jeff, he wanted to have the conversation about "why is the
> sandbox meaningless if we have this connection", though we know it won't be
> as good a sandboxing with it.

A connection to the X server can be used to read from or write to any window/drawable, inject input events, and poll the input devices.  I can see the argument that this would still raise the bar for meaningful exploitation as compared to control of an unrestricted process, but at the same it seems wrong to describe something as “sandboxed” if it can be turned into a clandestine remote access tool and keylogger.
(In reply to Jed Davis [:jld] from comment #4)
> (In reply to Milan Sreckovic [:milan] from comment #3)
> > CC-ing Jeff, he wanted to have the conversation about "why is the
> > sandbox meaningless if we have this connection", though we know it won't be
> > as good a sandboxing with it.
> 
> A connection to the X server can be used to read from or write to any
> window/drawable, inject input events, and poll the input devices.  I can see
> the argument that this would still raise the bar for meaningful exploitation
> as compared to control of an unrestricted process, but at the same it seems
> wrong to describe something as “sandboxed” if it can be turned into a
> clandestine remote access tool and keylogger.

Switching from using XRender for rendering is a requirement for this bug. It is currently planned but not really scheduled.
Depends on: 1134747
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> (In reply to Jed Davis [:jld] from comment #4)
> > (In reply to Milan Sreckovic [:milan] from comment #3)
> > > CC-ing Jeff, he wanted to have the conversation about "why is the
> > > sandbox meaningless if we have this connection", though we know it won't be
> > > as good a sandboxing with it.
> > 
> > A connection to the X server can be used to read from or write to any
> > window/drawable, inject input events, and poll the input devices.  I can see
> > the argument that this would still raise the bar for meaningful exploitation
> > as compared to control of an unrestricted process, but at the same it seems
> > wrong to describe something as “sandboxed” if it can be turned into a
> > clandestine remote access tool and keylogger.
> 
> Switching from using XRender for rendering is a requirement for this bug. It
> is currently planned but not really scheduled.

Further, we have the problem of GLX which we don't really have any plan to stop using, nor is there much of a replacement for it beyond using Wayland.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> Further, we have the problem of GLX which we don't really have any plan to
> stop using, nor is there much of a replacement for it beyond using Wayland.

For reference: Chromium on Linux also uses GLX, but the GL drivers and the X11 connection are in the GPU process, so a renderer process can't directly access them.
Noting for future reference: The MIT-SHM extension might also be a problem, because SysV shared memory follows Unix's “same uid policy” and can't be restricted/brokered like file access.  (It was observed when the initial attempt at a desktop content system call whitelist was made, but that was long enough ago that there could have been significant changes to how graphics work that might make this not a problem, so this should be double-checked.)  There's a not-well-specified revision to use memory-mapped files (http://patchwork.freedesktop.org/patch/15082/) but I don't know what would need to happen to make it work — Ubuntu 14.04 has a new enough X server and should (I think?) have new enough libraries, but X clients still empirically use SysV (including the Firefox parent process).

Comment 9

4 years ago
This should probably depend on bug 1180942

Updated

3 years ago
Whiteboard: sb+
Related work on exploiting a sandbox that allows X11 access: https://mjg59.dreamwidth.org/42320.html
Moving to sblc4 which deals with this issue.
Whiteboard: sb+ → sblc4

Updated

3 years ago
Component: Widget: Gtk → Security: Process Sandboxing
It would be worth looking into the Xorg sandboxing support (for servers compiled with --enable-xcsecurity) described here https://notehub.org/rp5n2.
(Assignee)

Comment 13

3 years ago
(In reply to Haik Aftandilian [:haik] from comment #12)
> It would be worth looking into the Xorg sandboxing support (for servers
> compiled with --enable-xcsecurity) described here https://notehub.org/rp5n2.

I tested this, and as Jed already suspected, it kills performance because GLX and OpenGL no longer work:
GLXtest process failed (exited with status 1): GLX extension missing.

This has a fairly extreme effect on performance for me.

There are also some undesirable side effects: I don't seem to be able to copy/paste from the untrusted process.
See Also: → 1326361
(Assignee)

Updated

2 years ago
Assignee: nobody → gpascutto
I tried using gdb to see what we're sending to the X server from the content process after sandbox startup.  If WebGL isn't used, the only thing I saw was, whenever a native widget is rendered in a new state, a GetInputFocus request sent by XSync() from this gdk_flush() call: https://searchfox.org/mozilla-central/rev/152c0296f8a10f81185ee88dfb4114ec3882b4c6/widget/gtk/nsNativeThemeGTK.cpp#1217

However, there doesn't appear to be anything that needs to be flushed/synchronized; that GetInputFocus message is the only thing in the buffer being sent to the server.  We seem to be doing the actual rendering to memory and handling it through our own IPC and compositor, which is good.  But it's not clear whether this is something we can depend on, and (if so) in what case that would hold; there's a lot of code that's being skipped due to conditionals like https://searchfox.org/mozilla-central/rev/152c0296f8a10f81185ee88dfb4114ec3882b4c6/gfx/2d/DrawTargetCairo.cpp#2329

It would be interesting, if WebGL is disabled or preffed off, to be able to just close the X11 connection or not even open it in the first place.  Failing that, if GLX is the only thing we need to deal with, then that could simplify the problem of proxying X11.

Another useful piece of information I've been told is that we don't ever use indirect GLX, because WebGL needs a newer version of OpenGL than that supports, so what we'd actually be sending over X11 is just for setting up out-of-band direct rendering, which could also make proxying a simpler problem.
There's also gfxPlatformGtk::GetPlatformCMSOutputProfile, which looks to be relatively easy to handle if needed (probably by sending down from the parent while setting up the content process): https://searchfox.org/mozilla-central/rev/5bb6dfcb3355a912c20383578bc435c1d4ecf575/gfx/thebes/gfxPlatformGtk.cpp#421

And this, which seems to be something about fonts and subpixel rendering: https://searchfox.org/mozilla-central/rev/5bb6dfcb3355a912c20383578bc435c1d4ecf575/gfx/thebes/gfxFcPlatformFontList.cpp#799
See Also: → 1376559

Updated

2 years ago
Priority: -- → P3
See Also: → 1503054
You need to log in before you can comment on or make changes to this bug.