kernel-hardening - Re: [PATCH] futex: do not leak robust list to unprivileged process

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Mar 2012 18:23:01 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	linux-kernel@...r.kernel.org, Darren Hart <dvhart@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Howells <dhowells@...hat.com>,
	kernel-hardening@...ts.openwall.com, spender@...ecurity.net
Subject: Re: [PATCH] futex: do not leak robust list to unprivileged process


* Kees Cook <keescook@...omium.org> wrote:

> On Tue, Mar 20, 2012 at 10:02 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Tue, 20 Mar 2012, Serge Hallyn wrote:
> >
> >> Quoting Kees Cook (keescook@...omium.org):
> >> > It was possible to extract the robust list head address from a setuid
> >> > process if it had used set_robust_list(), allowing an ASLR info leak. This
> >> > changes the permission checks to be the same as those used for similar
> >> > info that comes out of /proc.
> >> >
> >> > Running a setuid program that uses robust futexes would have had:
> >> >   cred->euid != pcred->euid
> >> >   cred->euid == pcred->uid
> >> > so the old permissions check would allow it. I'm not aware of any setuid
> >> > programs that use robust futexes, so this is just a preventative measure.
> >> >
> >> > (This patch is based on changes from grsecurity.)
> >> >
> >> > Signed-off-by: Kees Cook <keescook@...omium.org>
> >>
> >> I like the change.  Much cleaner.  I'm not 100% sure though that
> >> there are no legitimate cases of robust futexes use which would now
> >> be forbidden.  (Explicitly cc:ing Ingo)
> >
> > get_robust_list is not necessary for robust futexes. There is no
> > reference to get_robust_list in glibc.
> >
> > I really wonder why we have this syscall at all.
> 
> The documentation I found yesterday while looking at this was: 
> http://linux.die.net/man/2/get_robust_list
> 
> Which says "The system call is only available for debugging 
> purposes and is not needed for normal operations. Both system 
> calls are not available to application programs as functions; 
> they can be called using the syscall(3) function."
> 
> Dropping the syscall entirely would certainly make it secure. 
> ;)

The thinking was API completeness. In general it's possible for 
a sufficiently privileged task to figure out all the state of a 
task. We can query timers, fds - the robust list is such a 
resource as well. The information leakage was obviously not 
intended.

Thanks,

	Ingo

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.