oss-sec mailing list archives
Re: CVE Request -- kernel: futex: clear robust_list on execve
From: Solar Designer <solar () openwall com>
Date: Tue, 8 May 2012 04:08:17 +0400
On Wed, Jan 04, 2012 at 11:10:59PM +0100, Petr Matousek wrote:
Move "exit_robust_list" into mm_release() and clear them We don't want to get rid of the futexes just at exit() time, we want to drop them when doing an execve() too, since that gets rid of the previous VM image too. Doing it at mm_release() time means that we automatically always do it when we disassociate a VM map from the task. Upstream patches: 8141c7f3e7aee618312fa1c15109e1219de784a7 fc6b177dee33365ccb29fe6d2092223cf8d679f9 Reference: https://bugzilla.redhat.com/show_bug.cgi?id=771764
RHSA-2012:0107-1 summarizes this as: "A flaw was found in the way the Linux kernel handled robust list pointers of user-space held futexes across exec() calls. A local, unprivileged user could use this flaw to cause a denial of service or, eventually, escalate their privileges. (CVE-2012-0028, Important)" Is there a known attack vector (for either/both of the impacts mentioned above), and what is it? Here's what I arrived at after looking at the code for a little while: Indeed, execve() may make the new process relatively privileged (SUID, SGID, fscaps), and thus being able to write into its memory is a security issue. However, it appears that robust_list (and its compat counterpart) is only used for such writes when the process itself is exiting (with the aim being to notify other threads sharing the same mm). If so, the question is whether and how writes into an exiting process' memory may be exploited. We're already in do_exit() at this point, and it's just a few lines before we detach from and likely destroy the mm. Well, if that process itself is multi-threaded (and other threads are not exiting yet), it possibly can be exploited (through affecting those other threads). Is this the only attack scenario? Do we know of any SUID/SGID/fscaps-privileged multi-threaded programs? OK, I suppose that some proprietary ones exist (likely with plenty of vulnerabilities in them). ;-) BTW, kernel/fork.c: copy_process() resets the new process' or thread's robust_list pointers to NULL, but I think this does not prevent the scenario above because the parent's robust_list pointers are not reset and they're the ones that matter for attack against the new thread. However, this may help prevent the attack when there's a privileged wrapper around a multi-threaded program, if that wrapper does a fork() before execve()'ing the program. It is entirely possible that I have missed something crucial, and thus any/all of the above reasoning may be wrong. I'd appreciate any comments. Alexander
Current thread:
- Re: CVE Request -- kernel: futex: clear robust_list on execve Solar Designer (May 07)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Solar Designer (May 07)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Petr Matousek (May 09)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Solar Designer (May 09)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Petr Matousek (May 09)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Petr Matousek (May 09)
- Re: CVE Request -- kernel: futex: clear robust_list on execve Solar Designer (May 07)