All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	serge.hallyn@canonical.com, dvhart@linux.intel.com,
	a.p.zijlstra@chello.nl, jkosina@suse.cz, ebiederm@xmission.com,
	dhowells@redhat.com, keescook@chromium.org, tglx@linutronix.de
Cc: linux-tip-commits@vger.kernel.org
Subject: Re: [tip:core/locking] futex: Do not leak robust list to unprivileged process
Date: Tue, 19 Jun 2012 09:41:03 +0800	[thread overview]
Message-ID: <4FDFD8AF.6030209@cn.fujitsu.com> (raw)
In-Reply-To: <tip-bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8@git.kernel.org>

On 03/29/2012 05:55 PM, tip-bot for Kees Cook wrote:
> Commit-ID:  bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8
> Gitweb:     http://git.kernel.org/tip/bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8
> Author:     Kees Cook <keescook@chromium.org>
> AuthorDate: Mon, 19 Mar 2012 16:12:53 -0700
> Committer:  Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Thu, 29 Mar 2012 11:37:17 +0200
> 
> futex: Do not leak robust list to unprivileged process
> 
> 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.
> 

I'm not sure this change prevents the unprivileged process.
Please refer to LTP test, recently I saw that this change broke
the following test.

https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/get_robust_list/get_robust_list01.c#L155
		if (seteuid(1) == -1)
			tst_brkm(TBROK|TERRNO, cleanup, "seteuid(1) failed");

		TEST(retval = syscall(__NR_get_robust_list, 1,
				      (struct robust_list_head *)&head,
				      &len_ptr));

We set the euid to an unprivileged user, and expect to FAIL with EPERM,
without this patch, it FAIL as we expected, but with it, this call succeed.

Seems that we leaked the check of (cred->euid == pcred->euid && cred->euid == pcred->uid),
I'm not sure which one is right, can you please give an explanation?


Thanks in advance,
Wanlong Gao

> (This patch is based on changes from grsecurity.)
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: Darren Hart <dvhart@linux.intel.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
> Cc: kernel-hardening@lists.openwall.com
> Cc: spender@grsecurity.net
> Link: http://lkml.kernel.org/r/20120319231253.GA20893@www.outflux.net
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  kernel/futex.c        |   36 +++++++++++++-----------------------
>  kernel/futex_compat.c |   36 +++++++++++++-----------------------
>  2 files changed, 26 insertions(+), 46 deletions(-)
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 72efa1e..d701be5 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -59,6 +59,7 @@
>  #include <linux/magic.h>
>  #include <linux/pid.h>
>  #include <linux/nsproxy.h>
> +#include <linux/ptrace.h>
>  
>  #include <asm/futex.h>
>  
> @@ -2443,40 +2444,29 @@ SYSCALL_DEFINE3(get_robust_list, int, pid,
>  {
>  	struct robust_list_head __user *head;
>  	unsigned long ret;
> -	const struct cred *cred = current_cred(), *pcred;
> +	struct task_struct *p;
>  
>  	if (!futex_cmpxchg_enabled)
>  		return -ENOSYS;
>  
> +	rcu_read_lock();
> +
> +	ret = -ESRCH;
>  	if (!pid)
> -		head = current->robust_list;
> +		p = current;
>  	else {
> -		struct task_struct *p;
> -
> -		ret = -ESRCH;
> -		rcu_read_lock();
>  		p = find_task_by_vpid(pid);
>  		if (!p)
>  			goto err_unlock;
> -		ret = -EPERM;
> -		pcred = __task_cred(p);
> -		/* If victim is in different user_ns, then uids are not
> -		   comparable, so we must have CAP_SYS_PTRACE */
> -		if (cred->user->user_ns != pcred->user->user_ns) {
> -			if (!ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE))
> -				goto err_unlock;
> -			goto ok;
> -		}
> -		/* If victim is in same user_ns, then uids are comparable */
> -		if (cred->euid != pcred->euid &&
> -		    cred->euid != pcred->uid &&
> -		    !ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE))
> -			goto err_unlock;
> -ok:
> -		head = p->robust_list;
> -		rcu_read_unlock();
>  	}
>  
> +	ret = -EPERM;
> +	if (!ptrace_may_access(p, PTRACE_MODE_READ))
> +		goto err_unlock;
> +
> +	head = p->robust_list;
> +	rcu_read_unlock();
> +
>  	if (put_user(sizeof(*head), len_ptr))
>  		return -EFAULT;
>  	return put_user(head, head_ptr);
> diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
> index 5f9e689..a9642d5 100644
> --- a/kernel/futex_compat.c
> +++ b/kernel/futex_compat.c
> @@ -10,6 +10,7 @@
>  #include <linux/compat.h>
>  #include <linux/nsproxy.h>
>  #include <linux/futex.h>
> +#include <linux/ptrace.h>
>  
>  #include <asm/uaccess.h>
>  
> @@ -136,40 +137,29 @@ compat_sys_get_robust_list(int pid, compat_uptr_t __user *head_ptr,
>  {
>  	struct compat_robust_list_head __user *head;
>  	unsigned long ret;
> -	const struct cred *cred = current_cred(), *pcred;
> +	struct task_struct *p;
>  
>  	if (!futex_cmpxchg_enabled)
>  		return -ENOSYS;
>  
> +	rcu_read_lock();
> +
> +	ret = -ESRCH;
>  	if (!pid)
> -		head = current->compat_robust_list;
> +		p = current;
>  	else {
> -		struct task_struct *p;
> -
> -		ret = -ESRCH;
> -		rcu_read_lock();
>  		p = find_task_by_vpid(pid);
>  		if (!p)
>  			goto err_unlock;
> -		ret = -EPERM;
> -		pcred = __task_cred(p);
> -		/* If victim is in different user_ns, then uids are not
> -		   comparable, so we must have CAP_SYS_PTRACE */
> -		if (cred->user->user_ns != pcred->user->user_ns) {
> -			if (!ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE))
> -				goto err_unlock;
> -			goto ok;
> -		}
> -		/* If victim is in same user_ns, then uids are comparable */
> -		if (cred->euid != pcred->euid &&
> -		    cred->euid != pcred->uid &&
> -		    !ns_capable(pcred->user->user_ns, CAP_SYS_PTRACE))
> -			goto err_unlock;
> -ok:
> -		head = p->compat_robust_list;
> -		rcu_read_unlock();
>  	}
>  
> +	ret = -EPERM;
> +	if (!ptrace_may_access(p, PTRACE_MODE_READ))
> +		goto err_unlock;
> +
> +	head = p->compat_robust_list;
> +	rcu_read_unlock();
> +
>  	if (put_user(sizeof(*head), len_ptr))
>  		return -EFAULT;
>  	return put_user(ptr_to_compat(head), head_ptr);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



  reply	other threads:[~2012-06-19  1:42 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 23:12 [kernel-hardening] [PATCH] futex: do not leak robust list to unprivileged process Kees Cook
2012-03-19 23:12 ` Kees Cook
2012-03-20 13:31 ` [kernel-hardening] " Serge Hallyn
2012-03-20 13:31   ` Serge Hallyn
2012-03-20 17:02   ` [kernel-hardening] " Thomas Gleixner
2012-03-20 17:02     ` Thomas Gleixner
2012-03-20 17:11     ` [kernel-hardening] " Kees Cook
2012-03-20 17:11       ` Kees Cook
2012-03-20 17:23       ` [kernel-hardening] " Ingo Molnar
2012-03-20 17:23         ` Ingo Molnar
2012-03-22 23:46         ` [kernel-hardening] " Thomas Gleixner
2012-03-22 23:46           ` Thomas Gleixner
2012-03-23 17:58           ` [kernel-hardening] [PATCH] futex: mark get_robust_list as deprecated Kees Cook
2012-03-23 17:58             ` Kees Cook
2012-03-23 18:27             ` [kernel-hardening] " Thomas Gleixner
2012-03-23 18:27               ` Thomas Gleixner
2012-03-23 19:08               ` [kernel-hardening] " Kees Cook
2012-03-23 19:08                 ` Kees Cook
2012-03-23 19:08               ` [kernel-hardening] [PATCH v2] " Kees Cook
2012-03-23 19:08                 ` Kees Cook
     [not found]                 ` <20120323190855.GA27213-0X9Bc/hWBUTk6RaD4rd5nQ@public.gmane.org>
2012-03-23 22:06                   ` Eric W. Biederman
2012-03-23 22:06                     ` Eric W. Biederman
2012-03-23 22:06                     ` [kernel-hardening] " Eric W. Biederman
     [not found]                     ` <m1fwczvuph.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2012-03-23 22:10                       ` Kees Cook
2012-03-23 22:10                         ` Kees Cook
2012-03-23 22:10                         ` [kernel-hardening] " Kees Cook
2012-03-30  5:05                       ` Matt Helsley
2012-03-30  5:05                         ` Matt Helsley
2012-03-30  5:05                         ` [kernel-hardening] " Matt Helsley
2012-03-30 22:51                         ` Gene Cooperman
2012-03-30 22:51                           ` Gene Cooperman
     [not found]                         ` <20120330050544.GA32299-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2012-03-30  6:14                           ` Pavel Emelyanov
2012-03-30  6:14                             ` Pavel Emelyanov
2012-03-30  6:14                             ` [kernel-hardening] " Pavel Emelyanov
2012-03-30 22:51                           ` Gene Cooperman
2012-03-27 18:05                 ` [kernel-hardening] " Josh Boyer
2012-03-27 18:05                   ` Josh Boyer
2012-03-27 19:13                   ` [kernel-hardening] " Peter Zijlstra
2012-03-27 19:13                     ` Peter Zijlstra
2012-03-29  9:56                 ` [tip:core/locking] futex: Mark " tip-bot for Kees Cook
2012-08-02 10:35                 ` [kernel-hardening] Re: [PATCH v2] futex: mark " richard -rw- weinberger
2012-08-02 10:35                   ` richard -rw- weinberger
2012-08-02 11:11                   ` [kernel-hardening] " Eric W. Biederman
2012-08-02 11:11                     ` Eric W. Biederman
2012-08-03 10:17                     ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 10:17                       ` richard -rw- weinberger
2012-08-03 11:02                       ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:02                         ` Cyrill Gorcunov
2012-08-03 11:19                         ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:19                           ` richard -rw- weinberger
2012-08-03 11:27                           ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:27                             ` Cyrill Gorcunov
2012-08-03 11:30                             ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:30                               ` richard -rw- weinberger
2012-08-03 11:35                               ` [kernel-hardening] " Cyrill Gorcunov
2012-08-03 11:35                                 ` Cyrill Gorcunov
2012-08-03 11:38                                 ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 11:38                                   ` richard -rw- weinberger
2012-08-03 12:38                         ` [kernel-hardening] " Pavel Emelyanov
2012-08-03 12:38                           ` Pavel Emelyanov
2012-08-03 12:58                           ` [kernel-hardening] " Eric W. Biederman
2012-08-03 12:58                             ` Eric W. Biederman
2012-08-03 13:00                             ` [kernel-hardening] " richard -rw- weinberger
2012-08-03 13:00                               ` richard -rw- weinberger
2012-08-03 17:16                             ` [kernel-hardening] " Kees Cook
2012-08-03 17:16                               ` Kees Cook
2012-08-03 18:06                               ` [kernel-hardening] [PATCH] Revert "futex: Mark get_robust_list as deprecated" Richard Weinberger
2012-03-28 18:33           ` [kernel-hardening] Re: [PATCH] futex: do not leak robust list to unprivileged process Kees Cook
2012-03-28 18:33             ` Kees Cook
2012-03-28 21:24             ` [kernel-hardening] " Thomas Gleixner
2012-03-28 21:24               ` Thomas Gleixner
2012-03-29  9:55 ` [tip:core/locking] futex: Do " tip-bot for Kees Cook
2012-06-19  1:41   ` Wanlong Gao [this message]
2012-06-19  2:24     ` Serge Hallyn
2012-06-19  2:32       ` Wanlong Gao
2012-06-19  3:13         ` Serge Hallyn
2012-06-19  3:21           ` Wanlong Gao
2012-06-19 12:23             ` Serge Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDFD8AF.6030209@cn.fujitsu.com \
    --to=gaowanlong@cn.fujitsu.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dhowells@redhat.com \
    --cc=dvhart@linux.intel.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=serge.hallyn@canonical.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.