Messages in this thread | | | Subject | Re: [BUG] perf: bogus correlation of kernel symbols | From | Dan Rosenberg <> | Date | Fri, 20 May 2011 08:54:53 -0400 |
| |
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
| |