Bug#1082927: flatpak [LTS]: CVE-2024-42472: sandbox escape for apps with --persist=DIR permission
Source: flatpak
Version: 1.10.8-0+deb11u2
Severity: grave
Justification: user security hole
Tags: bullseye security
X-Debbugs-Cc: debian-lts@lists.debian.org
Control: found -1 1.2.5-0+deb10u4
Control: fixed -1 1.14.10-1~deb12u1
Control: fixed -1 1.14.10-1
Control: fixed -1 1.15.10-1
Advisory:
https://github.com/flatpak/flatpak/security/advisories/GHSA-7hgv-f2j8-xw87
This is fixed in stable, testing and unstable but I'm opening a bug to
represent this in (E)LTS. I am not intending to work on this vulnerability
in (E)LTS myself.
For context, Flatpak is a desktop-oriented app framework, allowing
sandboxed apps (potentially much newer than the base OS) to be
installed onto any distribution. I don't know whether the LTS team are
interested in supporting it or not: it will depend on your user-base. On
desktop/laptop-style interactive GUI systems, it might be considered
important/interesting for LTS because it's a way to install newer apps on
an old OS. Conversely, on servers and appliance-style embedded systems,
it's probably entirely uninteresting.
This particular vulnerability is awkward to fix because a complete
fix requires a new feature (the --bind-fd and --ro-bind-fd options)
in bubblewrap, one of Flatpak's dependencies.
There are several options for how it could be addressed:
1. Update bubblewrap to 0.10.0, and give Flatpak a versioned dependency
on it. This is what we did in unstable and experimental, and in the
Flatpak team's backports PPAs for Ubuntu noble and jammy:
https://salsa.debian.org/debian/flatpak/-/commit/0b47cdbb10d5183239299dba27053055d8fa1ec0
I imagine that (E)LTS will not want to do this.
2. Backport the --bind-fd feature to an older bubblewrap, give Flatpak a
suitable versioned dependency on it, and release both packages in a
single DLA. This is what we did for Flatpak 1.14.10 in Debian 12
'bookworm':
https://salsa.debian.org/debian/bubblewrap/-/commit/258ab8fb3a3faa54a811631d81fe43b9ca2d2936
https://salsa.debian.org/debian/flatpak/-/commit/37a25fd50181e93f5329c8cfbec7f69dce406a63
3. Instead of using the bwrap package, build Flatpak with its vendored
convenience copy (`--without-system-bubblewrap`), and if necessary
backport the new feature into that (in the 1.14.10 upstream release,
this was already done, by releasing bubblewrap 0.6.3 and updating the
vendored copy accordingly). This is what we did in the Flatpak team's
backports PPAs for Ubuntu focal and bionic:
https://github.com/flatpak/ppa-flatpak/commit/e22a18b1ba36c39515750bf1fcf99bf2206b7e0d
(bubblewrap and xdg-dbus-proxy are orthogonal, it is very easy to use
a vendored copy of one and a system copy of the other if you want)
4. Only apply a partial solution (mitigation) for the CVE, which doesn't
require touching bubblewrap. The gap here is that if an instance of a
malicious or compromised app runs in parallel with a second instance
being started, it can attempt to exploit a race condition to give the
second instance access to files outside the sandbox (probably difficult
to achieve in practice, but I'm not a professional exploit developer,
and maybe there is a trick that can make the timing easier).
5. Old versions of Flatpak are decreasingly useful as time goes on due to
third-party Flatpak apps requiring features of a newer Flatpak, so
if Flatpak is seen as important for LTS, the LTS team could decide to
base their flatpak package on bookworm/bullseye-backports instead of
on bullseye-security, similar to the way buster ELTS uses a backported
kernel. This is what I would personally do if I found myself wanting to
use Flatpak to install a newer third-party app onto a bullseye or even
buster system, but I realise it's contrary to how LTS usually works.
Upstream, we aim to avoid adding new dependencies to Flatpak 1.14.x for
as long as it is supported. The new dependency that was needed to fix
this CVE was exceptional, and we would not have done it if we saw
another option.
6. Or, if Flatpak is not seen as important for (E)LTS, the (E)LTS teams
could decide to add it to the list of packages with limited support
("only suitable for installing completely trusted apps"), or with no
security support at all.
For reference, the versions of flatpak and bubblewrap in various suites are:
* bookworm stable
- latest flatpak 1.14.x release, currently 1.14.10
- contains a vendored copy of bubblewrap 0.6.3, currently unused
- bubblewrap 0.8.0 + backported --bind-fd
* bullseye LTS
- flatpak 1.10.8 (1.10.x is recently EOL upstream)
- contains a vendored copy of bubblewrap from an intermediate commit
between 0.4.1 and 0.5.0, currently unused
- bubblewrap 0.4.1 + some backported bug fixes (similar to the version
vendored into flatpak 1.10.x)
* buster ELTS
- flatpak 1.2.5 (1.2.x is very much EOL upstream)
- contains a vendored copy of bubblewrap 0.3.0, currently unused
- bubblewrap 0.3.1 + backported bug fixes
Please choose whatever route to solving this the LTS team feels is most
appropriate.
Good luck,
smcv
Reply to: