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