[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Sep 2010 08:52:38 +0200
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Cc: Jon Oberheide <jon@...rheide.org>, security@...nel.org,
spender@...ecurity.net
Subject: Re: Re: [Security] Re: /proc infoleaks
On Tue, Sep 07, 2010 at 05:51:31PM -0400, Brad Spengler wrote:
>
> Definitely some work needs to be done here at the distro level, because
> it's pointless (as Enlightenment demonstrates) to hide /proc/kallsyms
> when /boot/System.map or /lib/modules are perfectly visible on any
> distro.
I agree that distros also have to do some homework there,
but there are things that we cant just do via init harden scripts.
Take /proc/pid/stack. Other files like my prefered friend /proc/net/netlink
gives info that allows exploitation-deluxe if you overwrite your socket destructor.
The list I have given was by no means complete (and even
didnt mean slabinfo will leak addresses, but was an example
of leaking other useful info) and I prefer an inventory
of 'problematic' /proc, /sys or whatever files if you speak
about inventory of programs using it.
> I know the impulse is to immediately copy what we're doing in
> grsecurity, but the reason we do some of the things in the way we do
Its always my first thought :)
> them is that we can be used on any distro and have no control over
> whatever distro that happens to be. We also support other features like
> PaX's KERNEXEC and UDEREF which make the symbol/address removal more
> useful. We're also able to make certain important assumptions about our
> users (eg. that they want security). So make sure you're thinking
> carefully about what you're trying to accomplish, why you're doing it,
> and how effective it will actually be given the (lack of) synergistic
> features at your present disposal, instead of jumping into cargo cult
> security.
Sure. It was just a proposal since I felt nobody really cared about
the low hanging fruits. It wont make your system rocket proof but
it makes some head-scratching for exploit developers which is
all you need if you make them stuck in doing that.
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.
