Date: Wed, 18 Sep 2013 09:06:54 -0600 From: Vincent Danen <vdanen@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: Fwd: [vs-plain] polkit races * [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@...e.de> ----- > >From: Sebastian Krahmer <krahmer@...e.de> >To: distros@...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@...e.de - SuSE Security Team > > > >----- End forwarded message ----- > >-- > >~ perl self.pl >~ $_='print"\$_=\47$_\47;eval"';eval >~ krahmer@...e.de - SuSE Security Team > -- Vincent Danen / Red Hat Security Response Team
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