From: Ingo Molnar <mingo@elte.hu>
To: Kyle McMartin <kyle@mcmartin.ca>
Cc: Marcus Meissner <meissner@suse.de>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
tj@kernel.org, akpm@osdl.org, hpa@zytor.com, w@1wt.eu,
alan@lxorguk.ukuu.org.uk,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking
Date: Thu, 18 Nov 2010 08:48:04 +0100 [thread overview]
Message-ID: <20101118074804.GC32621@elte.hu> (raw)
In-Reply-To: <20101117050759.GE22651@bombadil.infradead.org>
* Kyle McMartin <kyle@mcmartin.ca> wrote:
> On Tue, Nov 16, 2010 at 11:46:03AM +0100, Marcus Meissner wrote:
> > Target of this starter patch and follow ups is removing any kind of
> > kernel space address information leak from the kernel.
> >
>
> Er. Should probably hit /proc/modules while you're at it.
Agreed. A few other kernel address things that should be hidden are:
1) /proc/<PID>/stack
Gives out kernel addresses and is a partial /proc/kallsyms table in essence. This
got introduced recently. Useful to attackers.
Then there's a handful of physical address leaks - those are less useful but useful
in some situations:
2) /proc/mtrr
Gives some idea about the physical layout of the machine and can give information
about the location of certain physical devices as well. Limited but nonzero utility
to attackers.
3) /proc/asound/cards
Can gives out the physical address of a device. Limited but nonzero utility to
attackers.
4) /sys/devices/*/*/resources
Shows physical addresses. Limited but nonzero utility to attackers.
Plus there's some really limited fractional pieces of information - again, of
nonzero utility to attackers:
5) /proc/net/ptype
Shows the sizes of a few kernel functions in networking code. Very limited but
nonzero utility to attackers.
6) /sys/kernel/slab/*/ctor
Shows the sizes of a few kernel functions. Very limited but nonzero utility to
attackers.
7) /sys/module/*/sections/*
For example:
/sys/module/sunrpc/sections/__bug_table
/sys/module/sunrpc/sections/__ex_table
/sys/module/sunrpc/sections/__ksymtab
/sys/module/sunrpc/sections/__ksymtab_gpl
/sys/module/sunrpc/sections/__ksymtab_strings
/sys/module/sunrpc/sections/__mcount_loc
/sys/module/sunrpc/sections/__param
Potentially useful to attackers.
There's probably a few more i missed.
Ingo
next prev parent reply other threads:[~2010-11-18 7:49 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-16 10:46 [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking Marcus Meissner
2010-11-17 5:07 ` Kyle McMartin
2010-11-18 7:48 ` Ingo Molnar [this message]
2010-11-20 3:18 ` Kees Cook
2010-11-26 7:51 ` Ingo Molnar
2010-11-17 5:40 ` Kyle Moffett
2010-11-17 5:41 ` Kyle Moffett
2010-11-17 5:58 ` Linus Torvalds
2010-11-17 6:19 ` Willy Tarreau
2010-11-18 7:31 ` Ingo Molnar
2010-11-23 17:24 ` Pavel Machek
2010-11-26 7:38 ` Ingo Molnar
2010-11-29 19:03 ` H. Peter Anvin
2010-11-20 11:32 ` Avi Kivity
2010-11-19 19:19 ` Sarah Sharp
2010-11-19 19:54 ` Linus Torvalds
2010-11-19 19:58 ` david
2010-11-19 20:04 ` Linus Torvalds
2010-11-19 20:16 ` Willy Tarreau
2010-11-19 20:55 ` david
2010-11-26 7:48 ` Ingo Molnar
2010-11-29 16:33 ` Sarah Sharp
2010-11-29 18:04 ` Ingo Molnar
2010-11-29 19:05 ` H. Peter Anvin
2010-11-29 19:21 ` Eric Paris
2010-11-29 19:38 ` H. Peter Anvin
2010-11-29 21:49 ` Willy Tarreau
2010-11-29 23:31 ` Alan Cox
2010-11-30 11:58 ` Ingo Molnar
2010-11-20 11:05 ` Richard W.M. Jones
-- strict thread matches above, loose matches on Subject: below --
2010-11-19 21:12 Andy Walls
2010-11-19 23:22 ` Linus Torvalds
2010-11-20 2:40 ` Kees Cook
2010-11-20 19:47 ` Henrique de Moraes Holschuh
2010-11-29 22:58 ` Kevin Easton
2010-11-04 10:09 Marcus Meissner
2010-11-04 10:11 ` Tejun Heo
2010-11-04 11:46 ` Ingo Molnar
2010-11-04 12:29 ` Marcus Meissner
2010-11-04 13:58 ` Ingo Molnar
2010-11-04 14:11 ` Ingo Molnar
2010-11-04 14:33 ` Marcus Meissner
2010-11-04 14:38 ` Tejun Heo
2010-11-04 14:43 ` H. Peter Anvin
2010-11-04 14:48 ` Tejun Heo
2010-11-04 19:08 ` Ingo Molnar
2010-11-07 18:02 ` Andi Kleen
2010-11-07 18:32 ` H. Peter Anvin
2010-11-10 8:53 ` Ingo Molnar
2010-11-11 2:51 ` H. Peter Anvin
2010-11-11 7:05 ` Ingo Molnar
2010-11-05 2:38 ` Frank Rowand
2010-11-10 20:58 ` Jesper Juhl
2010-11-05 0:20 ` Jesper Juhl
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=20101118074804.GC32621@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=meissner@suse.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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