[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120508000817.GA13604@openwall.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
