Open Bug 1673188 Opened 4 years ago Updated 3 years ago

GTK theme parser in content processes violates seccomp sandbox

Categories

(Core :: Security: Process Sandboxing, defect, P2)

Firefox 81
defect

Tracking

()

UNCONFIRMED

People

(Reporter: alexbuzzbee, Unassigned)

References

Details

Attachments

(1 file)

Attached file gtk.css

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

  1. Install Firefox on a Linux system.
  2. Put a wrong gtk.css in ~/.config/gtk-3.0; in my case, @define-color lines with empty rgb()s. Minimal example attached.
  3. Launch Firefox in a terminal emulator.

Actual results:

When each content process starts, it generates (uncolored) GTK and seccomp errors of the form:

Sandbox: seccomp sandbox violation: pid 23082, tid 23082, syscall 16, args 2 21523 140724416056152 0 1 0.

(/usr/lib/firefox/firefox:23082): Gtk-WARNING **: 17:07:30.405: Theme parsing error: gtk.css:1:44: Invalid number for color value

The system call is an ioctl(stderr, TIOCGWINSZ, ...), which is used by many programs to tell terminals and other files apart.

My best guess on what is happening is as follows:

  1. GTK's theme parser runs inside the content process.
  2. It reads and tries to parse gtk.css.
  3. It encounters a CSS error and tries to report it.
  4. GTK's logging code checks whether stderr is a terminal with ioctl(stderr, TIOCGWINSZ, ...).
  5. seccomp-bpf denies the ioctl.
  6. SIGSYS, sandbox error.
  7. GTK's logging code decides to use non-terminal mode and writes uncolored error output.
  8. The content process moves on to some other initialization step.

Expected results:

One of:

  • GTK is not loaded in web content processes.
  • GTK is somehow blocked from parsing themes in content processes.
  • The sandbox allows ioctl TIOCGWINSZ at least on standard files (stdin, stdout, stderr).

I'm not sure why my User-Agent says Firefox/78.0; About Firefox says Firefox 81, and so does my package manager.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

The plan is to remove GTK usage in the content process.

Depends on: linux-nnt

Sounds good to me.

Priority: -- → P3

Given that this case doesn't really break functionality (it happens if the config is broken...), I'm not sure we'd want to address this in the sandbox filter itself, though it probably is possible, see e.g.: https://searchfox.org/mozilla-central/source/security/sandbox/linux/SandboxFilter.cpp#859

Component: Widget: Gtk → Security: Process Sandboxing
Priority: P3 → --
Whiteboard: sb?

I wouldn't consider changing the filter the best solution. Removing GTK from the content processes is definitely a better solution, especially given its multiple other benefits.

Severity: -- → S4
Priority: -- → P2

The more usual way to find out if it's possible to print fancy error messages is to call isatty which (at least in glibc) uses tcgetattr which is TCGETS, which we deny with ENOTTY rather than going into the “invalid syscall” case. We could do the same thing to TIOCGWINSZ.

Good point about the C libraries, should probably have mentioned that. I'm using a system that uses musl as its libc, and I've just checked to confirm and musl does in fact use TIOCGWINSZ for isatty():

https://git.musl-libc.org/cgit/musl/tree/src/unistd/isatty.c

So that means that to see this bug you need to be:

  1. Running Firefox...
  2. In a terminal emulator...
  3. On a Linux system...
  4. That uses musl...
  5. With a broken GTK CSS file.

Not exactly the most obvious or important bug in the world.

Whiteboard: sb?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: