lkml.org 
[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] perf: bogus correlation of kernel symbols

* Dan Rosenberg <drosenberg@vsecurity.com> wrote:

> I was able to boot a relocatable kernel with the decompression location at a
> hard-coded offset without too much trouble. Everything seems to work fine.

Nice!

> However, it occurred to me that even if the kernel image's base address were
> randomized at boot, assuming a binary distro kernel it would still be
> possible to sidt the address of the IDT and calculate symbol offsets relative
> to that. Any thoughts on how to avoid that? Seems difficult. Another hurdle
> will be to find a reasonable source of entropy that early in the boot
> process.

I do not think it's an issue.

If an attacker can execute arbitrary privileged instructions like SIDT then
it's game over. There's plenty of CPU state, the IDT, GDT, various MSRs that
would tell roughly where the kernel is, etc.

The attack randomization protects against is when the attacker has a limited
amount of control over a stack return address (due to a buffer overflow for
example) and can redirect kernel execution to some 'interesting' place that
allows more control. With SMEP and kernel image randomization this would be
rather difficult to pull off: the kernel wont jump to a pre-prepared user-space
shellcode buffer (due to SMEP) while the location of already existing,
executable, supervisor-privileged pages is randomized.

So when you have implemented this i'd suggest enabling CONFIG_X86_PTDUMP=y to
get access to a dump of all pagetables, in the /debug/kernel_page_tables file.
There you can check every single executable, kernel-privileged mapping on a
live system and make sure it's not easily discovered.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-05-20 14:11    [W:0.138 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site