Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Sep 2010 07:47:31 -0400
From: Brad Spengler <spender@...ecurity.net>
To: Sebastian Krahmer <krahmer@...e.de>
Cc: oss-security@...ts.openwall.com, Jon Oberheide <jon@...rheide.org>,
	security@...nel.org
Subject: Re: Re: [Security] Re:  /proc
	infoleaks

> 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.

That's true too -- I was just talking about the ones mentioned in the 
original post.  /proc/pid/stack goes away when you disable 
CONFIG_STACKTRACE btw, but the best solution going forward (as a lot of 
these and other infoleaks have been added recently through new features) 
is this: the internals of the kernel should be a black box to 
unprivileged processes.  This needs to be considered by the people who 
write and approve these new features that push out all kinds of 
information via /proc and elsewhere.  If it doesn't get considered 
before it goes into the kernel, then we have to play this game after the 
fact of staying compatible with apps that now depend on that behavior.

> 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.

Be careful about assuming head-scratching -- if something can be worked 
around (like in the kallsyms case), it only takes one person.  Everyone 
else can reuse that work without any head-scratching.

-Brad

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

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.