Your message dated Mon, 30 Sep 2024 10:22:02 +0100 with message-id <[email protected]> and subject line Re: Bug#1082927: flatpak [LTS]: CVE-2024-42472: sandbox escape for apps with --persist=DIR permission has caused the Debian Bug report #1082927, regarding flatpak [LTS]: CVE-2024-42472: sandbox escape for apps with --persist=DIR permission to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1082927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082927 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: flatpak Version: 1.10.8-0+deb11u2 Severity: grave Justification: user security hole Tags: bullseye security X-Debbugs-Cc: [email protected] 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
--- End Message ---
--- Begin Message ---Version: 1.14.10-1 On Sat, 28 Sep 2024 at 14:24:41 +0100, Simon McVittie wrote: > This is fixed in stable, testing and unstable Closing this on that basis. It remains relevant in LTS, but the LTS team is presumably used to how the BTS's version tracking works. smcv
--- End Message ---
_______________________________________________ Pkg-utopia-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
