Date: Tue, 8 May 2012 04:08:17 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: CVE Request -- kernel: futex: clear robust_list on execve 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ