Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening

[Kees Cook <keescook@chromium.org>]

On Tue, Sep 1, 2015 at 2:03 AM, Jiri Kosina <jikos@kernel.org> wrote:
> On Mon, 31 Aug 2015, Eric W. Biederman wrote:
>
>> At the same time I think we to serious consider tossing attempts that
>> fails to close a class of exploits.
>>
>> The kernel address space randomization on x86_64 I find disturbing.  We
>> have a 2GB address space for kernel code.  We have pages that are 2MB in
>> that address space.  So we only have 10 bits that can change.  Only 9
>> bits that can change if the kernel needs more than one 2MB page.  Which
>> means that at most we need to brute force 1024 things to exploit any
>> weakness.
>
> I understand what you are saying. OTOH, assuming that kernel doesn't leak
> addressess when restrict_kptr is set, it's rather likely that bruteforcing
> attempt to exploit the kernel is going to crash it instead of privilege
> escalation happenin (because the address wouldn't match, and either the
> kernel will #GP directly, or do some totally random garbage and crash
> shortly afterwards).
>
> It's still *pretty* bad, but arguably better than being silently
> compromised without anyone noticing.

This reminds me: we must assume all users on a system (and all devices
being attached) have access to a write-anywhere primitive (since they
DO -- we just haven't found them all yet, and we never will), what can
we do to close the windows of exploitability? (e.g. making memory
read-only, adding CFI to defend against ROP via the stack, etc?)

-Kees

-- 
Kees Cook
Chrome OS Security