lkml.org 
[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] perf: bogus correlation of kernel symbols
From
Date
On Fri, 2011-05-20 at 14:07 +0200, Ingo Molnar wrote:
> * 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.
>

Except that SIDT isn't a privilege instruction, it's accessible as ring
3.

> 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.
>

Yes, all true, except are you specifically considering remote-only
attack vectors?

> 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.
>

I'll do this too, but first I'd like to address the above.

Thanks,
Dan

> Thanks,
>
> Ingo




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