It was reported that when executing a program via "pkexec --user nonpriv program", the nonpriv session can escape to the parent session by using the TIOCSTI ioctl to push characters into the terminal's input buffer, allowing privilege escalation.
Original bug report (contains reproducer):
https://bugzilla.redhat.com/showbug.cgi?id=1299955
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.
A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the polkit-agent-helper-1 setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system.