Re: Fwd: [vs-plain] polkit races

[Vincent Danen <vdanen () redhat com>]

* [2013-09-18 14:15:49 +0200] Sebastian Krahmer wrote:

Probably should have noted the related CVEs.  Since this affects not
only polkit, but the usage of such by other applications, this is a
(probably preliminary) list of CVEs and applications affected:

CVE-2013-4288 polkit: unix-process subject for authorization is racy
CVE-2013-4311 libvirt: insecure calling of polkit via libgobject API
CVE-2013-4324 spice-gtk: use of insecure polkit libgobject-1 API
CVE-2013-4325 hplip: use of insecure polkit DBUS API
CVE-2013-4326 rtkit: use of insecure polkit DBUS API
CVE-2013-4327 systemd: use of insecure polkit DBUS API

I will be opening up our bugs shortly, but all of these are in the Red
Hat bugzilla and should provide more specifics (they can be found by
visiting https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-????


> Hi list
>
> As required by distros list policy, I forward this to oss-security.
> The initial CRD was Sept 11th, but it was shifted to today as
> there were so many packages to be fixed.
>
> regards
> Sebastian
>
> ----- Forwarded message from Sebastian Krahmer <krahmer () suse de> -----
>
> From: Sebastian Krahmer <krahmer () suse de>
> To: distros () vs openwall org
> Subject: [vs-plain] polkit races
> Date: Wed, 28 Aug 2013 10:17:37 +0200
>
> Hi
>
> The polkit unix-process subject for authorization is racy. It depended
> on the (PID, startup_time) pair to be passed to polkit which then used /proc/PID/status
> to find out the UID the process belongs to. Meanwhile the process could
> have started a suid or pkexec process, changing the euid and/or uid at will.
> The startup_time does not protect here, as its not changed across an execve().
>
> Using /proc/PID/loginuid wont work either, as one could abuse fork-spawning
> processes such as sshd, apache etc. to re-use recently freed process slots,
> faking the loginuid. startup_time would theoretically help here, yet as
> its not atomically passed along the message which is subject to polkit
> authorization, the privileged process needs to learn it by looking up
> /proc/PID/, which is racy again.
>
> Therefore the only thing that could be used is the UID that is passed
> atomically in the peer cred struct when receiving the message in question.
>
> The whole thing needs fixing in polkit, to deprecate PID authorization
> as well as several core packages to make use of the new API, or use
> systembus authorization.
>
> After discussing with upstream, Colin Walters made this private git of patches
> available:
>
> http://people.freedesktop.org/~walters/secret/38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b/
>
> Feel free to suggest improvements if necessary.
>
> As required by list policy, I request a CRD of Sept 11th.
>
> We also need CVE's assigned.
>
> A PoC with example client/server which demonstrates the race
> can be found here (it basically simulates libvirtd's way of
> checking):
>
> http://suse.de/~krahmer/priv/polkit-race.tgz
>
> Sebastian
>
> --
>
> ~ perl self.pl
> ~ $_='print"\$_=\47$_\47;eval"';eval
> ~ krahmer () suse de - SuSE Security Team
>
>
>
> ----- End forwarded message -----
>
> --
>
> ~ perl self.pl
> ~ $_='print"\$_=\47$_\47;eval"';eval
> ~ krahmer () suse de - SuSE Security Team

--
Vincent Danen / Red Hat Security Response Team