[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101107232934.GD17592@basil.fritz.box>
Date: Mon, 8 Nov 2010 00:29:34 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: chas3@...rs.sourceforge.net, Andi Kleen <andi@...stfloor.org>,
Ted Ts'o <tytso@....edu>,
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
> So the only question is whether kernel pointers are an information
> leak worth worrying about. Personally, I think it's just damn stupid
> to expose a kernel pointer unless you _have_ to. There is absolutely
Agreed.
> no reason to expose the address of a socket in /proc, perhaps unless
> you're in some super-duper-debugging mode that no sane person would
> ever use outside of specialized network debugging (and I bet that in
> that case you still shouldn't expose it in a _normal_ proc file, but
> in debugfs or something).
In most cases you can get them by running gdb or crash on /proc/kcore
anyways.
Still overall I suspect there may be a case that making
dmesg root only is a good idea. At least optionally for the non
kernel hackers out there.
The early memory map information can be likely used to guess a lot of
locations and perhaps really make that heap overflow easier to write.
And perhaps some more mapping randomization inside the kernel.
I'm not sure the case is very strong though.
-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
Powered by blists - more mailing lists