linux-kernel - Re: [RFC PATCH 1/2] proc: force dcache drop on unauthorized access

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110922175754.GA6558@albatros>
Date:	Thu, 22 Sep 2011 21:57:54 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	kernel-hardening@...ts.openwall.com,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] proc: force dcache drop on unauthorized access

Hello Andrew,

On Sat, Sep 10, 2011 at 20:40 +0400, Vasiliy Kulikov wrote:
> The patch "proc: fix races against execve() of /proc/PID/fd**" is still
> a partial fix for a setxid problem.  link(2) is a yet another way to
> identify whether a specific fd is opened by a privileged process.  By
> calling link(2) against /proc/PID/fd/* an attacker may identify whether
> the fd number is valid for PID by analysing link(2) return code.
> 
> Both getattr() and link() can be used by the attacker iff the dentry is
> present in the dcache.  In this case ->lookup() is not called and the
> only way to check ptrace permissions is either operation handler or
> ->revalidate().  The easiest solution to prevent any unauthorized access
> to /proc/PID/fd*/ files is to force the dentry drop on each unauthorized
> access attempt.
> 
> If an attacker keeps opened fd of /proc/PID/fd/ and dcache contains
> a specific dentry for some /proc/PID/fd/XXX, any future attemp to use the
> dentry by the attacker would lead to the dentry drop as a result of a
> failed ptrace check in ->revalidate().  Then the attacker cannot spawn a
> dentry for the specific fd number because of ptrace check in ->lookup().
> 
> The dentry drop can be still observed by an attacker by analysing
> information from /proc/slabinfo, which is addressed in the successive
> patch.

After (almost) everybody agreed that closing slabinfo and similar is
a good thing, should I resend these 2 patches (/proc/PID/fd and
slabinfo) with sysfs addition or you'll take these patches and I'll send
sysfs patch after them?

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/