[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 18 Apr 2024 17:47:18 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: flatpak-security@...ts.freedesktop.org, flatpak@...ts.freedesktop.org
Subject: flatpak CVE-2024-32462 : Sandbox escape via RequestBackground portal
and CWE-88
Flatpak is a system for building, distributing, and running sandboxed
desktop applications on Linux.
Gergo Koteles discovered a sandbox escape when using Flatpak in
conjunction with xdg-desktop-portal.
For patches and any updated information that becomes available, please see:
https://github.com/flatpak/flatpak/security/advisories/GHSA-phv6-cpc2-2fgj
Impact
======
A malicious or compromised Flatpak app could execute arbitrary code
outside its sandbox.
Fixed versions
==============
* flatpak 1.14.x >= 1.14.6 (stable branch)
* flatpak 1.12.x >= 1.12.9 (old stable branch)
* flatpak 1.10.x >= 1.10.9 (old stable branch)
* flatpak >= 1.15.8 (development branch)
Older flatpak branches such as 1.8.x are EOL and will not receive new
upstream releases.
Vulnerable versions
===================
* flatpak 1.15.x before 1.15.8
* flatpak 1.14.x before 1.14.6
* flatpak 1.12.x before 1.12.9
* all versions before 1.10.9
Description
===========
Normally, the --command argument of flatpak run expects to be given a
command to run in the specified Flatpak app, optionally along with some
arguments. For example:
flatpak run --command=ls org.gnome.gedit
The original implementation of this was subject to CWE-88: in Flatpak
versions that have this vulnerability, it is possible to pass a long
option name to --command=, such as --bind, and it will be misinterpreted
as a bwrap(1) option. For example, one may do
flatpak run --command=--bind org.gnome.gedit / /host ls -l /host
Which will run:
bwrap ...lots of stuff... --bind / /host ls -l /host
It is possible to pass an arbitrary `commandline` to the portal interface
org.freedesktop.portal.Background.RequestBackground from within a Flatpak
app. Normally this is safe, because it can only specify a command that
exists inside the sandbox; but when a crafted `commandline` is converted
into a --command and arguments, the app could achieve the same effect of
passing arguments directly to bwrap, and therefore achieve sandbox escape.
The solution is for Flatpak to use the -- argument to bwrap, which makes
it stop processing options, before appending the attacker-specified
command:
bwrap ...lots of stuff... -- --bind / /host ls -l /host
which will attempt to run a command named `--bind` from the sandboxed app's
PATH (unlikely to work in practice).
The -- argument has been supported since bubblewrap 0.3.0, and all
supported versions of Flatpak already require at least that version
of bubblewrap.
A mitigation is that xdg-desktop-portal version 1.18.4 will no longer
allow Flatpak apps to create new .desktop files for commands that start
with -.
Test-case
=========
1. Install any Flatpak app, for example org.gnome.Recipes
2. flatpak run --command=--help org.gnome.Recipes
(replacing the app ID with whatever app you chose)
Good result (not vulnerable):
bwrap: execvp --help: No such file or directory
Bad result (vulnerable): the same help text as `bwrap --help`.
--
Simon McVittie, Collabora Ltd. / Debian
on behalf of the Flatpak maintainers
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
