netdev - Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101107231421.GC17592@basil.fritz.box>
Date:	Mon, 8 Nov 2010 00:14:21 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	chas3@...rs.sourceforge.net
Cc:	Andi Kleen <andi@...stfloor.org>, Ted Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dan Rosenberg <drosenberg@...curity.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
	"pekkas@...core.fi" <pekkas@...core.fi>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"remi.denis-courmont@...ia.com" <remi.denis-courmont@...ia.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"security@...nel.org" <security@...nel.org>
Subject: Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via
 /proc

On Sun, Nov 07, 2010 at 05:48:45PM -0500, Chas Williams (CONTRACTOR) wrote:
> In message <87sjzcssx5.fsf@...il.nowhere.org>,Andi Kleen writes:
> >Ted Ts'o <tytso@....edu> writes:
> >
> >> Are there any userspace programs that might be reasonably expected to
> >> _use_ this information?  If there is, we could just pick a random
> >> number at boot time, and then XOR the heap adddress with that random
> >> number.
> >
> >If any of the addresses can be guessed ever (and that is likely if it's
> >allocated at boot) determining the random value will be trivial
> >for everyone.
> 
> i suppose one could use idr to map the pointers to unique values.  the
> infiniband code uses this technique>

idr requires allocating memory, and it's unclear you can do that
in all the situations where debugging printks are used. And
how would you get the idr table out of a broken kernel? And further
the memory allocations would eventually fill up your memory
if they go on. I don't think idr is a solution.

I don't really have a good solution either. Even if the
the individual pointers were removed from printks (which
probably doesn't make much difference anyways because those
printks usually happen only in unlikely debug situations):

The information about the memory layout early on in dmesg
is probably enough to make a good educated guess about
the locations of standard slab caches on a known kernel
image. For example the first N sockets opened are very likely
easy to guess this way.

I guess one could make dmesg root only, although I personally
use it often as non root.

Or maybe add some more randomization to the buddy allocator.
The drawback of that is that they tend to make
benchmarks unstable due to cache coloring differences.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html