linux-kernel - Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:	Wed, 9 Feb 2011 22:38:42 -0800
From:	Kees Cook <kees.cook@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	Al Viro <viro@....linux.org.uk>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	linux-security-module@...r.kernel.org
Subject: Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec

On Wed, Feb 09, 2011 at 07:41:41PM -0800, Eric W. Biederman wrote:
> James Morris <jmorris@...ei.org> writes:
> 
> > On Tue, 8 Feb 2011, Eric W. Biederman wrote:
> >
> >> Kees Cook <kees.cook@...onical.com> writes:
> >> 
> >> > On Tue, Feb 08, 2011 at 02:43:15PM +1100, James Morris wrote:
> >
> >> >> > I don't think /proc/$pid/* needs to stay open across execs, does it? Or at
> >> >> > least the non-0444 files should be handled separately.
> >> >> 
> >> >> Actually, this seems like a more general kind of bug in proc rather than a 
> >> >> leaked fd.  Each child task should only see its own /proc/[pid] data.
> >> >
> >> > Right, that's precisely the problem. The unprivileged process can read
> >> > the setuid process's /proc files.
> >> 
> >> If these are things that we actually care about we should sprinkle in a
> >> few more ptrace_may_access calls into implementations of the relevant
> >> proc files.
> >
> > This seems to be papering over a bug.
> >
> > It is plainly broken to return an access error to a task which is 
> > legitimately accessing a file.  The task should not receive the wrong 
> > information from /proc/[pid]/* .
> 
> Per task files are special because of exec.  The permission needed
> change dynamically.  The common solution to this problem (see ttys) is
> to revoke anyone who has file descriptors open.  Proc does something a
> little different and simply gives you a permission error when you read
> or write if it would be a problem.
> 
> We happen to call the test to see if you should have permission
> security_may_ptrace because ptrace lets you get the information anyway
> so we might as well allow the information from /proc.
> 
> Given that security_may_ptrace is the existing model, and that we don't
> return wrong data, but a clear an unambiguous error I don't see problems
> with the approach.
> 
> The practical question is, is the data sensitive enough that we want
> this protection.

This seems reasonable; they're mode 0400 for a reason. The auxv file
alone is a nearly total ASLR offset leak. The may_ptrace() worked well
for /proc/$pid/maps, and it started as 0444 historically and had a lot
of additional carefully managed requirements. Adding the same restriction
to all the already-mode-0400 files seems logical.

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/