http://lists.freedesktop.org/archives/polkit-devel/2011-April/000349.html http://bugzilla.redhat.com/show_bug.cgi?id=692922 Quoting upstream: I was contacted privately about a potential vulnerability in polkitd and pkexec. Briefly, the problem is that the UID for the parent process of pkexec(1) is read from /proc by stat(2)'ing /proc/PID. The problem with this is that this returns the effective uid of the process which can easily be set to 0 by invoking a setuid-root binary such as /usr/bin/chsh in the parent process of pkexec(1). Instead we are really interested in the real-user-id. While there's a check in pkexec.c to avoid this problem (by comparing it to what we expect the uid to be - namely that of the pkexec.c process itself which is the uid of the parent process at pkexec-spawn-time), there is still a short window where an attacker can fool pkexec/polkitd into thinking that the parent process has uid 0 and is therefore authorized. It's pretty hard to hit this window - I actually don't know if it can be made to work in practice. Either way, if exploitable (which I think it is), this bug is a local root exploit so we should treat it like that. Now that there is no vendor-sec list anymore, I don't know what it means wrt to embargoing? (so far this issue has been kept confidential - and the patches fixing this are not yet publicly available) I already have patches for polkit master to fix this problem (to look up the right uid) and also avoid having to look up the UID in /proc/PID at all (doing so is generally causes TOCTTOU bugs). These patches should all work in the polkit versions shipped in supported versions of Fedora. I am right now working on patches for RHEL6.
Thank you for this, Samuli. Are we ok to start stabilization of =sys-auth/polkit-0.101-r1?
These need to go stable all at the same time: =dev-libs/glib-2.28.6 =sys-auth/polkit-0.101-r1 =gnome-extra/polkit-gnome-0.101-r1 =www-client/epiphany-2.30.6-r1 =gnome-base/gnome-session-2.32.1-r2 =gnome-base/gnome-control-center-2.32.1-r1 =gnome-base/gvfs-1.6.7 (bug 363789) =www-client/midori-0.3.3 (bug 364773) =dev-util/desktop-file-validate-0.18 (bug 364971)
(In reply to comment #2) > =dev-util/desktop-file-validate-0.18 (bug 364971) *desktop-file-utils, sorry
=dev-libs/gobject-introspection-0.10.8 also
Can we make 363789 364773 364971 depend on this bug and stabilize the entire list of ebuilds via this bug? Just thinking it gives the arches one place to look...
(In reply to comment #5) > Can we make 363789 364773 364971 depend on this bug and stabilize the entire > list of ebuilds via this bug? Just thinking it gives the arches one place to > look... It already does depend on them. I guess you meant to unCC arch's there and move them here? Yes, please do that. Also I just posted a required news item for the glib stabilization to gentoo-dev and gave people 24 hours to comment on it, however I don't see any reason why we shouldn't go ahead with this bug even before that...
(In reply to comment #6) > It already does depend on them. I guess you meant to unCC arch's there and > move them here? Yes, please do that. > Actually, I had it backwards. ;) I meant make those bug depend on this one, but that is a very minor thing. I'll make the CC changes now. Thank you. > Also I just posted a required news item for the glib stabilization to > gentoo-dev and gave people 24 hours to comment on it, however I don't see any > reason why we shouldn't go ahead with this bug even before that... Great, thank you.
Arches, please test and mark stable the following packages. Please use new bugs to report or track any failures. Thank you. =sys-auth/polkit-0.101-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" =dev-libs/glib-2.28.6 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" =gnome-extra/polkit-gnome-0.101-r1 Target keywords : "alpha amd64 arm ia64 ppc ppc64 sh sparc x86" =www-client/epiphany-2.30.6-r1 Target keywords : "alpha amd64 ia64 ppc ppc64 sparc x86" =gnome-base/gnome-session-2.32.1-r2 Target keywords : "alpha amd64 arm ia64 ppc ppc64 sparc x86" =gnome-base/gnome-control-center-2.32.1-r1 Target keywords : "alpha amd64 arm ia64 ppc ppc64 sh sparc x86" =gnome-base/gvfs-1.6.7 Target keywords : "alpha amd64 arm ia64 ppc ppc64 sh sparc x86" =www-client/midori-0.3.3 Target keywords : "amd64 x86" =dev-util/desktop-file-utils-0.18 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" =dev-libs/gobject-introspection-0.10.8 Target keywords : "alpha amd64 arm ia64 ppc ppc64 s390 sh sparc x86"
all seems ok here( without bug 365001 ) Posted also bug 364989 already fixed by eva.
(In reply to comment #8) > Arches, please test and mark stable the following packages. Please use new bugs > to report or track any failures. Thank you. > You missed one, from bug 364971: =x11-misc/shared-mime-info-0.90 "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" And the NEWS item is also now committed, so there shouldn't be any blockers left.
ppc/ppc64 stable
amd64 stable
Stable for HPPA.
x86 stable; I've done a simple restart test twice to make sure we have no obvious "boot ****up".
alpha/arm/ia64/m68k/s390/sh/sparc stable
Thanks, folks. GLSA request filed.
CVE-2011-1485 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1485): Race condition in the pkexec utility and polkitd daemon in PolicyKit (aka polkit) 0.96 allows local users to gain privileges by executing a setuid program from pkexec, related to the use of the effective user ID instead of the real user ID.
Created attachment 288857 [details] polkit-pwnage.c http://blog.zx2c4.com/675 Since it’s been 6 months since reported, I figure it’s been a responsible amount of time for me to wait before releasing a local root exploit for Linux that targets polkit-1 <= 0.101, CVE-2011-1485, a race condition in PolicyKit. I present you with PolicyKit Pwnage. [...]
This issue was resolved and addressed in GLSA 201204-06 at http://security.gentoo.org/glsa/glsa-201204-06.xml by GLSA coordinator Sean Amoss (ackle).