From: Andi Kleen <andi@firstfloor.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: chas3@users.sourceforge.net, Andi Kleen <andi@firstfloor.org>,
Ted Ts'o <tytso@mit.edu>,
Dan Rosenberg <drosenberg@vsecurity.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
"pekkas@netcore.fi" <pekkas@netcore.fi>,
"jmorris@namei.org" <jmorris@namei.org>,
"yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>,
"kaber@trash.net" <kaber@trash.net>,
"remi.denis-courmont@nokia.com" <remi.denis-courmont@nokia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"security@kernel.org" <security@kernel.org>
Subject: Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via /proc
Date: Mon, 8 Nov 2010 00:29:34 +0100 [thread overview]
Message-ID: <20101107232934.GD17592@basil.fritz.box> (raw)
In-Reply-To: <AANLkTikDeVXcYRXqcq-qD_mf19awnKPTYGZbZguxJLDm@mail.gmail.com>
> 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@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-11-07 23:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 20:11 [SECURITY] Fix leaking of kernel heap addresses via /proc Dan Rosenberg
2010-11-06 20:50 ` [Security] " Linus Torvalds
2010-11-06 23:48 ` Ted Ts'o
2010-11-07 21:52 ` Andi Kleen
2010-11-07 22:48 ` Chas Williams (CONTRACTOR)
2010-11-07 23:14 ` Andi Kleen
2010-11-07 23:22 ` Linus Torvalds
2010-11-07 23:29 ` Andi Kleen [this message]
2010-11-07 23:27 ` Dan Rosenberg
2010-11-07 23:56 ` Andi Kleen
2010-11-08 2:01 ` David Miller
2010-11-08 7:33 ` Eric Dumazet
2010-11-08 9:43 ` Andi Kleen
2010-11-08 10:14 ` Eric Dumazet
2010-11-06 23:57 ` David Miller
2010-11-07 10:28 ` Oliver Hartkopp
2010-11-07 17:11 ` Ben Hutchings
2010-11-08 1:00 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101107232934.GD17592@basil.fritz.box \
--to=andi@firstfloor.org \
--cc=chas3@users.sourceforge.net \
--cc=davem@davemloft.net \
--cc=drosenberg@vsecurity.com \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=pekkas@netcore.fi \
--cc=remi.denis-courmont@nokia.com \
--cc=security@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).