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

[Kees Cook <keescook@chromium.org>]

On Mon, Aug 24, 2015 at 10:28 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Aug 24, 2015 at 10:17 AM, Kees Cook <keescook@chromium.org> wrote:
>> 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. :)
>>
>
> What is this chipset knowledge you speak of? :)

You appear to enjoy fixing deep x86 madness. :)

> One thing that grsecurity addresses (partially or fully?  I haven't
> looked that closely): we have tons of static, non-const data structure
> that contain function pointers, and we can't make them const because
> they get filled in when things are initialized.  Grsecurity mitigates
> this with some combination of compiler plugins and pax_open_kernel,

Right. That's the constification and KERNEXEC pieces.

> but we could probably come up with a more straightforward solution.
> We could add an ro_after_init section, or we could even have a section
> for things that are const but are writable through a special function.

I don't think it would be that clean: there are many targets that
legitimately need updating at runtime, but should be otherwise
read-only. The idea with solving that is to use inline
open/close_kernel calls to make them writable briefly and in a way
that is ROP-defensive.

>>>>
>>>> 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)
>
> We still need to do something about the direct map, IIRC.  Or did we
> already fix that?

We have a lot of targets still, but we're headed (slowly) in the right
direction.

>>  Protect sensitive data
>>  o Constify function pointers! (no where close to this plugin)
>
> As above, this would be nice.  If we did this upstream, we could do
> even better if we outright disallowed non-const function pointers (as
> opposed to fixing them up semi-transparently as the plugin does).

I would love this. :)

>>  o IDT/GDT/syscall table/etc (this is partially done, aliases are
>> writable still)
>
> I don't think the RO GDT patches ever happened.
>
> FWIW, we can't really eliminate a writable GDT alias without killing
> compat performance: set_thread_area rather critically depends on
> writing to the GDT at context switch time.

If that's what's needed, I am fine killing compat performance. (We
could attempt to make this a CONFIG for those that expect to run
compat loads for their kernels.)

>>  o Vsyscall shadow table, see sgrakkyu's remote
>> SELinux-disabling exploit
>> (http://sgrakkyu.antifork.org/sctp_houdini.c, luto fixed this via
>> vsyscall emulation)
>
> Not done yet, because even modern binaries still have the thing
> mapped.  We could devote two or three minutes of a KS session to
> figuring out how to kill it off for real for modern binaries.

What uses it? I can run with vsyscall=none without problems...

>> 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.
>
> At the risk of poking a big elephant, I think we should do something
> about perf, too.  Perf is really useful, but it's also a *huge* attack
> surface.

No disagreement from me.

-Kees

-- 
Kees Cook
Chrome OS Security