|
Message-ID: <20100908065238.GA30023@suse.de> 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.