[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100907083546.GA19866@suse.de>
Date: Tue, 7 Sep 2010 10:35:46 +0200
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Cc: security@...nel.org, spender@...ecurity.net
Subject: /proc infoleaks
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.
I know that hardening patches already have these
secure defaults; with reason. Making kernel exploits
has been really too easy in past if you get all the
mem layout and symbols for free. Of course that doesnt
free one from writing good code but its about time
(since years actually) to raise the level.
regards,
Sebastian
--
~
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security Team
~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
