FS#23851 - [polkit] UID for the parent process of pkexec is read from /proc by stat'ing /proc/PID
Attached to Project:
Arch Linux
Opened by Greg (dolby) - Wednesday, 20 April 2011, 08:34 GMT
Last edited by Ionut Biru (wonder) - Sunday, 01 May 2011, 07:33 GMT
Opened by Greg (dolby) - Wednesday, 20 April 2011, 08:34 GMT
Last edited by Ionut Biru (wonder) - Sunday, 01 May 2011, 07:33 GMT
|
Details
"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)" Details here: http://lists.freedesktop.org/archives/polkit-devel/2011-April/000349.html |
This task depends upon
Comment by Jan de Groot (JGC) -
Wednesday, 20 April 2011, 09:49 GMT
Fixed in testing, still working on an update for extra. We're
using 0.99 at the moment, patches for 0.96 and 0.101 don't apply
to that version. Moving the testing version to extra will pull in
glib2 with some side-effects on packages in extra.