GTK theme parser in content processes violates seccomp sandbox
Categories
(Core :: Security: Process Sandboxing, defect, P2)
Tracking
()
People
(Reporter: alexbuzzbee, Unassigned)
References
Details
Attachments
(1 file)
47 bytes,
text/css
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- Install Firefox on a Linux system.
- Put a wrong gtk.css in ~/.config/gtk-3.0; in my case, @define-color lines with empty rgb()s. Minimal example attached.
- 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:
- GTK's theme parser runs inside the content process.
- It reads and tries to parse gtk.css.
- It encounters a CSS error and tries to report it.
- GTK's logging code checks whether stderr is a terminal with ioctl(stderr, TIOCGWINSZ, ...).
- seccomp-bpf denies the ioctl.
- SIGSYS, sandbox error.
- GTK's logging code decides to use non-terminal mode and writes uncolored error output.
- 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).
Reporter | ||
Comment 1•4 years ago
|
||
I'm not sure why my User-Agent says Firefox/78.0; About Firefox says Firefox 81, and so does my package manager.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
The plan is to remove GTK usage in the content process.
Reporter | ||
Comment 3•4 years ago
|
||
Sounds good to me.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
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
Reporter | ||
Comment 5•4 years ago
|
||
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.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
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
.
Reporter | ||
Comment 7•3 years ago
|
||
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:
- Running Firefox...
- In a terminal emulator...
- On a Linux system...
- That uses musl...
- With a broken GTK CSS file.
Not exactly the most obvious or important bug in the world.
Updated•3 years ago
|
Description
•