Messages in this thread | | | Date | Fri, 20 May 2011 15:11:08 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |