oss-security September 2010 archive
Main Archive Page > Month Archives  > oss-security archives
oss-security: [oss-security] Re: [Security] /proc infoleaks

[oss-security] Re: [Security] /proc infoleaks

From: Sebastian Krahmer <krahmer_at_nospam>
Date: Tue Sep 07 2010 - 11:13:45 GMT
To: Andrew Morton <akpm@linux-foundation.org>

On Tue, Sep 07, 2010 at 03:51:03AM -0700, Andrew Morton wrote:
> On Tue, 7 Sep 2010 10:35:46 +0200 Sebastian Krahmer <krahmer@suse.de> wrote:
>
> > I have been elected to receive the bashing from all sides,
> > so here we go.
> > It is not about a new vulnerability or even a new discussion
> > but needs to be discussed, at least that we have a clear
> > statement about the status quo.
> >
> > Recent i-CAN-haz-MODHARDEN.c has shown once *again* that
> > certain file permissions make no sense except to exploitation
> > development. There is no reason to have files like
> >
> > /proc/kallsyms
> > /proc/slabinfo
> > /proc/zoneinfo
> >
> > and probably a lot of others world readable. The symbol
> > addresses might be hard-coded for a certain targetlist
> > inside the exploit so you can argue that there
> > wont be any protection benefit from making it unreadable.
> > However this argument aint a reason to also leak it for self-compiled
> > kernels and doesnt even hold for dynamic/runtime content
> > like slabinfos etc.
> > It would be nice to have something like
> >
> > echo 1 > /proc/quiet
> >
> > or something like a umask for kernel-owned proc
> > entries so that you have a polite default and are
> > still able to enable it for certain profiling tools
> > or whereever you need it.
>
> chmod 0440 /proc/slabinfo
>
Heh, indeed. :-)
Would it be a bad idea to have proc_create() use a more strict
mode so it is non-leaking by default?

Sebastian

-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)