Date: Fri, 23 Jun 2017 08:12:39 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: CVE-2017-9780: Flatpak: privilege escalation via setuid/world-writable file permissions On Fri, 23 Jun 2017 at 07:37:54 +0200, Florian Weimer wrote: > On 06/22/2017 11:01 PM, Simon McVittie wrote: > > * If you are using Flatpak to install apps from a third-party vendor, > > then there is already a trust relationship: the app is sandboxed, but > > the third-party vendor chooses what parameters are used for the sandbox. > > Doesn't this qualify as a vulnerability in its own right? Flatpak > advertises countermeasures against malicious applications Hmm, yes, that mitigation is overstated. The extent of the trust relationship depends whether you consider the arbiter of app permissions to be the user of Flatpak (who has the opportunity to check and deny requested permissions, but will frequently not take that opportunity) or the repository maintainer (the app author sets the permissions that will be used in the absence of further user action, and the repository maintainer chooses what apps they are willing to publish). The flatpak(1) low-level CLI tool is non-interactive (CLI, not TUI), so it can't prompt for acceptance/rejection of permissions, but they can be viewed between installation and run with "flatpak info", and taken away (or indeed added) with "flatpak override". I believe the intention is that interactive GUIs for Flatpak (like GNOME Software) will query requested permissions in advance, more like the way Android does it. CVE-2017-9780 applies after merely installing a Flatpak app, even if the user intends to remove permissions before running it, so it breaks that model. > Flatpak's sandboxing technology prevents exploits and hinders malicious > applications. I think "prevents exploits" is stronger than is justified (I didn't write that text). If nothing else, most current Linux desktops use X11, which has very little privilege separation; and in practice GUI Flatpak apps all ask for access to the X11 socket, because otherwise their GUIs would not work on non-Wayland systems. The sandbox certainly *hinders* malicious applications - in particular some aspects of the sandbox, such as NO_NEW_PRIVS, cannot be turned off by configuration - but it is not enough to render malicious code harmless to run. I would recommend talking to Flatpak's maintainer directly if you have comments on this - I am not going to be adding useful value by acting as a man-in-the-middle. S  Where possible, user consent for actions outside the sandbox is obtained at the time of use by "portals": for instance opening a file outside the sandbox is mediated by an ordinary File->Open dialog running outside the sandbox, and only the user-selected file is made available inside the sandbox. However, not all permissions are feasible to use this way; in particular, the framework needs to know when the app is run whether to set up an isolated network namespace or allow sharing the host's network namespace. In the above, and when I wrote "parameters for the sandbox" in the advisory, I mean the permissions that can't be prompted for on-use.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ