[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170623071216.ddio6ve4f54yy2hf@perpetual.pseudorandom.co.uk>
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[1], 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
[1] 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
