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
