An anonymous reporter discovered that Flatpak apps with direct access to AF_UNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can trick portals and other host-OS services into treating the Flatpak app as though it was an ordinary, non-sandboxed host-OS process, by manipulating the VFS using recent mount-related syscalls that are not blocked by Flatpak's denylist seccomp filter, in order to substitute a crafted /.flatpak-info or make that file disappear entirely.
Impact
Flatpak apps that act as clients for AF_UNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can escalate the privileges that the corresponding services will believe the Flatpak app has.
Mitigation: Note that protocols that operate entirely over the D-Bus session bus (user bus), system bus or accessibility bus are not affected by this. This is due to the use of a proxy process xdg-dbus-proxy, whose VFS cannot be manipulated by the Flatpak app, when interacting with these buses.
Patches
The short-term solution is to expand the deny-list of syscalls in the seccomp filter:
These follow-up fixes address regressions in the initial version:
- d419fa6 (included in 1.12.1 and 1.10.5)
- 3fc8c67 (included in 1.12.2, should be included in 1.10.6)
The regression fixes are necessary for compatibility with Flatpak apps, runtimes and extensions that use the extra-data feature (such as openh264 and the proprietary NVIDIA drivers) or that use multiarch (such as Steam). However, they weaken the protection against unwanted system calls: system calls not known to the installed version of libseccomp will not be blocked. Using a version of libseccomp at least as new as the currently-running kernel is recommended. We are looking for better long-term solutions.
Follow-up hardening is likely to convert the deny-list into an allow-list, and/or block namespace transitions in some other way.
Workarounds
None currently known.
For more information
If you have any questions or comments about this advisory, please contact flatpak-security at lists.freedesktop.org.
An anonymous reporter discovered that Flatpak apps with direct access to AF_UNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can trick portals and other host-OS services into treating the Flatpak app as though it was an ordinary, non-sandboxed host-OS process, by manipulating the VFS using recent mount-related syscalls that are not blocked by Flatpak's denylist seccomp filter, in order to substitute a crafted
/.flatpak-infoor make that file disappear entirely.Impact
Flatpak apps that act as clients for AF_UNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can escalate the privileges that the corresponding services will believe the Flatpak app has.
Mitigation: Note that protocols that operate entirely over the D-Bus session bus (user bus), system bus or accessibility bus are not affected by this. This is due to the use of a proxy process
xdg-dbus-proxy, whose VFS cannot be manipulated by the Flatpak app, when interacting with these buses.Patches
The short-term solution is to expand the deny-list of syscalls in the seccomp filter:
These follow-up fixes address regressions in the initial version:
The regression fixes are necessary for compatibility with Flatpak apps, runtimes and extensions that use the extra-data feature (such as openh264 and the proprietary NVIDIA drivers) or that use multiarch (such as Steam). However, they weaken the protection against unwanted system calls: system calls not known to the installed version of libseccomp will not be blocked. Using a version of libseccomp at least as new as the currently-running kernel is recommended. We are looking for better long-term solutions.
Follow-up hardening is likely to convert the deny-list into an allow-list, and/or block namespace transitions in some other way.
Workarounds
None currently known.
For more information
If you have any questions or comments about this advisory, please contact
flatpak-securityatlists.freedesktop.org.