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:

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

Oops, stupid me :-/

We need to allocate the IDT dynamically: just kmalloc() it, update idt_descr
and do a load_idt(). Double check places that modify idt_descr or use
idt_table.

Note, you could do this as a side effect of a nice performance optimization:
would you be interested in allocating it in the percpu area, using
percpu_alloc()? That way the IDT is distributed between CPUs - this has
scalability advantages on NUMA systems and maybe even on SMP.

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

No, unprivileged local user, so yes, the IDT address has to be protected.

Thanks,

Ingo


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