[Pkg-utopia-maintainers] Bug#1082927: flatpak [LTS]: CVE-2024-42472: sandbox escape for apps with --persist=DIR permission

[Simon McVittie]

Source: flatpak
Version: 1.10.8-0+deb11u2
Severity: grave
Justification: user security hole
Tags: bullseye security
X-Debbugs-Cc: debian-lts at 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