linux-kernel - Re: [RFC][PATCH] Randomize kernel base address on boot

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110528063241.GA22399@elte.hu>
Date:	Sat, 28 May 2011 08:32:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Olivier Galibert <galibert@...ox.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dan Rosenberg <drosenberg@...curity.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tony Luck <tony.luck@...il.com>,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	adobriyan@...il.com, penberg@...nel.org, hpa@...or.com,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Valdis.Kletnieks@...edu, pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot

* Olivier Galibert <galibert@...ox.com> wrote:

> On Fri, May 27, 2011 at 08:17:24PM +0200, Ingo Molnar wrote:
> >  - A root exploit will still not give away the location of the
> >    kernel (assuming module loading has been disabled after bootup),
> >    so a rootkit cannot be installed 'silently' on the system, into
> >    RAM only, evading most offline-storage-checking tools.
> > 
> >    With static linking this is not possible: reading the kernel image
> >    as root trivially exposes the kernel's location.
> 
> There's something I don't get there.  If you managed to escalate your
> priviledges enough that you have physical ram access, there's a
> billion things you can do to find the kernel, including vector
> tracing, pattern matching, looking at the page tables, etc.
>
> What am I missing?

You are missing that it's not unrealistic to make the
"root does not have physical RAM access" condition true
on a system.

CONFIG_STRICT_DEVMEM=y will go a long way already, enabled
on most distros these days:

 $ grep DEVMEM $(rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep boot/config)
 CONFIG_STRICT_DEVMEM=y

Combined with:

 echo 1 > /proc/sys/kernel/modules_disabled

( Which cannot be turned back on once turned off after essential 
  modules have loaded. )

Admins do not actually need access to physical RAM, nor do they need
the ability to binary patch kernel code, so it's not unrealistic to
do this in distros.

There can be a few more vectors to access physical RAM but they can 
be controlled as well.

This will already force a reboot (or a wait for a regular reboot) by 
the attacker to install rootkit level code.

But yes, if root controls RAM then it's obviously game over: even 
with randomization RAM can be scanned for kernel image signatures, 
kernel code can be inserted or system call table patched - q.e.d.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/