[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100908114731.GA11762@grsecurity.net>
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.
