lkml.org 
[lkml]   [2011]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Randomize kernel base address on boot

* Dan Rosenberg <drosenberg@vsecurity.com> wrote:

> > No, the right solution is what i suggested a few mails ago:
> > /proc/kallsyms (and other RIP printing places) should report the
> > non-randomized RIP.
> >
> > That way we do not have to change the kptr_restrict default and
> > tools will continue to work ...
>
> Ok, I'll do it this way, and leave the kptr_restrict default to 0.
> But I still think having the dmesg_restrict default depend on
> randomization makes sense, since kernel .text is explicitly
> revealed in the syslog.

Hm, where is it revealed beyond intcall addresses, which ought to be
handled if they are printed via %pK?

All such information leaks need to be fixed. (This will be the
slowest part of the process i suspect - there's many channels.)

in the syslog we obviously want any RIPs converted to the canonical
'unrandomized' address, so that it can be matched against
/proc/kallsyms, etc. Their randomized value isnt very useful. That
will also protect the randomization secret as a side effect.

The only thorny issue AFAICS are oopses. There's real value in having
'raw' data from a crash (interpreting crashes is hard enough even
without randomization!), OTOH we could keep most of the value of them
by converting them back to canonical addresses.

This would be more or less easy to do for the RIP and the registers,
but less obvious for the stack: a kernel pointer can lie on the stack
at arbitrary alignment. On 64-bit we could probably detect them
rather reliably based on the randomized prefix of kernel addresses:

[ 32.946003] Stack:
[ 32.946003] 0000000000000202 0000000000000002 0000000000000001 0000000000000000
[ 32.946003] 0000000000000198 0000000000000002 0000000000000000 00000000002ca5b0
[ 32.946003] 0000000000000000 ffff88003e5533e0 ffff88003f977c00 ffffffff802225e3

the ffffffff8 prefix (assuming we end up randomizing the address
within the 2GB window available to a RIP-relative addressed kernel)
would be easy to detect even if it's not word aligned. There *would*
be false positives (a 32-bit value of -7 is common), but as long as
we marked any unrandomization clearly with an asterix:

[ 32.946003] Stack:
[ 32.946003] 0000000000000202 0000000000000002 0000000000000001 0000000000000000
[ 32.946003] 0000000000000198 0000000000000002 0000000000000000 00000000002ca5b0
[ 32.946003] 0000000000000000*ffff88003e5533e0*ffff88003f977c00*ffffffff802225e3

we'd be informed that the stack content was slighly different. If we
fixed up register values, say the raw value is:

[ 32.946003] RDX: 0000000000000000 RSI: ffffffff80ce0100 RDI: 0000000000000000

and randomization is -0x100000 then we'd print the normalized value
for 'RSI':

[ 32.946003] RDX: 0000000000000000 RSI:*ffffffff80de0100 RDI: 0000000000000000

And the '*' tells us that this value got normalized.

On 32-bit systems the rate of false positive is probably higher, he
'0xc0' byte pattern is pretty common.

Now, theoretically there's still a tiny information hole here: if an
attacker can crash a kernel in a non-fatal way that puts some known
data on the kernel stack, then the unrandomization will reveal the
secret ...

I guess we'll have to live with that: really paranoid places will
disable dmesg access to unprivileged users.

[ They might also want to have a knob to not log kernel crashes at
all - best protection is if *no one* (not even root) has a way to
figure out the secret. That needs to go hand in hand with forced
use of signed modules, sanitized /dev/mem, no root-controllable DMA
access to any device, no ioperm() and iopl(), etc. - so a very
locked down kernel that protects even root from being able to
execute kernel code. Such systems are still useful btw even if root
otherwise has access to all disks and has access to the kernel
image and can install its own image: a reboot will generally set
off an alarm. ]

> Thanks very much for the feedback.

Hey, thanks for taking up on implementing this rather non-trivial
security feature!

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-05-25 13:27    [W:0.119 / U:6.440 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site