Bug 364973 (CVE-2011-1485) – <sys-auth/polkit-0.101-r1: Local privilege escalation (CVE-2011-1485)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Samuli Suominen (RETIRED) 2011-04-26 18:39:21 UTC]

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.

[Comment 1 Tim Sammut (RETIRED) 2011-04-26 18:43:36 UTC]

Thank you for this, Samuli. Are we ok to start stabilization of =sys-auth/polkit-0.101-r1?

[Comment 2 Samuli Suominen (RETIRED) 2011-04-26 18:44:23 UTC]

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)

[Comment 3 Samuli Suominen (RETIRED) 2011-04-26 18:46:43 UTC]

(In reply to comment #2)
> =dev-util/desktop-file-validate-0.18 (bug 364971)

*desktop-file-utils, sorry

[Comment 4 Samuli Suominen (RETIRED) 2011-04-26 18:47:57 UTC]

=dev-libs/gobject-introspection-0.10.8 also

[Comment 5 Tim Sammut (RETIRED) 2011-04-26 18:50:46 UTC]

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...

[Comment 6 Samuli Suominen (RETIRED) 2011-04-26 18:56:48 UTC]

(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...

[Comment 7 Tim Sammut (RETIRED) 2011-04-26 19:04:37 UTC]

(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.

[Comment 8 Tim Sammut (RETIRED) 2011-04-26 19:16:58 UTC]

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"

[Comment 9 Agostino Sarubbo 2011-04-26 22:23:27 UTC]

all seems ok here( without bug 365001 )

Posted also bug 364989 already fixed by eva.

[Comment 10 Samuli Suominen (RETIRED) 2011-04-27 13:48:28 UTC]

(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.

[Comment 11 Kacper Kowalik (Xarthisius) (RETIRED) 2011-04-27 13:53:36 UTC]

ppc/ppc64 stable

[Comment 12 Christoph Mende (RETIRED) 2011-04-27 14:22:48 UTC]

amd64 stable

[Comment 13 Jeroen Roovers (RETIRED) 2011-04-27 17:00:26 UTC]

Stable for HPPA.

[Comment 14 Paweł Hajdan, Jr. (RETIRED) 2011-04-28 10:35:15 UTC]

x86 stable; I've done a simple restart test twice to make sure we have no obvious "boot ****up".

[Comment 15 Raúl Porcel (RETIRED) 2011-04-30 17:48:59 UTC]

alpha/arm/ia64/m68k/s390/sh/sparc stable

[Comment 16 Tim Sammut (RETIRED) 2011-04-30 22:31:36 UTC]

Thanks, folks. GLSA request filed.

[Comment 17 GLSAMaker/CVETool Bot 2011-06-24 00:25:26 UTC]

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.

[Comment 18 Francesco Riosa 2011-10-05 12:01:03 UTC]

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.

[...]

[Comment 19 GLSAMaker/CVETool Bot 2012-04-17 23:44:35 UTC]

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).