[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Fwd: [vs-plain] polkit races
From:       Vincent Danen <vdanen () redhat ! com>
Date:       2013-09-18 15:06:54
Message-ID: 20130918150654.GM2414 () redhat ! com
[Download RAW message or body]

* [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 


[prev in list] [next in list] [prev in thread] [next in thread]