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

[Kees Cook <keescook@chromium.org>]

On Mon, Aug 24, 2015 at 4:56 AM, James Morris <jmorris@namei.org> wrote:
> On Mon, 24 Aug 2015, Jiri Kosina wrote:
>
>> On Mon, 24 Aug 2015, James Morris wrote:
>>
>> > I'd recommend Kees Cook be involved, due to his existing efforts in
>> > kernel hardening.  I think it would be good to invite one or two expert
>> > security researchers in this area -- Kees would know who.  In terms of

Many of the folks that are good at kernel exploitation don't want to
help us fix the situation. :)

I'd recommend Lee Campbell, he's got a solid bit of experience from
the offense side. I think we should extend an invite to spender and
pageexec as well. They've been on the cutting edge of this for
decades, and it would be silly not to invite them.

>> > core kernel folk, I'd suggest Ingo and akpm, as a starting point.

Perhaps also Linus and rmk? Some of the protections are very central
to the kernel (e.g. constification, "read-mostly", segmentation
through page table swaps or domains, etc). I'd also want Andy
Lutomirski around, as he's got a lot of deep chipset knowledge. :)

>>
>> I am pretty sure spender will also have a lot to tell us :p
>
> He actually presented at the 2010 security summit:
> https://grsecurity.net/spender_summit.pdf

This was his bullet list of things that grsecurity/PaX already does
and that should be in mainline (with my notes in parens). He suggested
it would take us 10 years to catch up. We're 5 years into that, with
only a few things partially off this list:

 Remove infoleaks
 o Symbol information (partial improvement via kptr_restrict)
 o Slabinfo (partial improvement with 0400 root perms)
 o PAX_USERCOPY (even if gcc fixed their sizeof bug, we'd be no where
near this plugin's level of protection)
 Remove RWX from kernel (in good shape on x86, started on arm)
 Protect sensitive data
 o Constify function pointers! (no where close to this plugin)
 o IDT/GDT/syscall table/etc (this is partially done, aliases are
writable still)
 o Vsyscall shadow table, see sgrakkyu's remote
SELinux-disabling exploit
(http://sgrakkyu.antifork.org/sctp_houdini.c, luto fixed this via
vsyscall emulation)
Protect against invalid userland memory
accesses in general (SMEP and SMAP on x86 get us this, but it can be
emulated or done differently e.g. ARM domains)
Make refcount overflows unexploitable (nothing done on this front)
 o Currently equivalent to use-after-free
kmalloc(sizeof(somestruct) * attacker_len) (some partial improvements
here to replace this anti-pattern manually)
 o See recent ethtool get_rxnfc() vulnerability
Basically, secure the kernel! Your super finegrained
security systems will thank you

This is far from a comprehensive list, though. The biggest value, I
think, would be in using KERNEXEC, UDEREF, USERCOPY, and the plugins
for constification and integer overflow.

> I'm not sure he'd be interested in working with us on this, though.

As I understand him, he's quite binary about his methods: either it's
done totally right, or it's not worth doing at all. With that in mind,
I think his position is clear, even if he's rather prickly. :)

-Kees

-- 
Kees Cook
Chrome OS Security