[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jL8x8TTwgJpRJUjM3erfrv7-49YHEKm_Lo3F46FumdWzw@mail.gmail.com>
Date: Thu, 5 Apr 2018 12:20:24 -0700
From: Kees Cook <keescook@...omium.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: Kurt Seifried <kseifried@...hat.com>, oss-security@...ts.openwall.com,
James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
Brad Spengler <spender@...ecurity.net>, PaX Team <pageexec@...email.hu>,
"Reshetova, Elena" <elena.reshetova@...el.com>
Subject: Re: Linux Kernel Defence Map
On Thu, Apr 5, 2018 at 5:32 AM, Alexander Popov <alex.popov@...ux.com> wrote:
> On 05.04.2018 01:17, Kees Cook wrote:
>> (I think "info leaks" and "finding kernel objects" may need some kind
>> of clarifying language for how they're different)
>
> Info Exposure is a vulnerability (red node). STACKLEAK, PAGE_POISONING, etc
> mitigate this kind of bugs.
>
> Finding Kernel Objects is an exploitation technique (orange node). KASLR,
> RANDSTRUCT are statistical defences which make it harder for an adversary.
>
> Kees, Kurt, does it sound reasonable?
Yeah, that makes sense.
>> Upstream's /proc/sys/net/core/bpf_jit_harden (see commit 4f3446bb809f)
>
> Thanks, added.
>
>> and other JIT features (RO-setting, randomized offset, etc) are
>> designed to defend against JIT Abuse.
>
> Didn't manage to find config for them. Are they always enabled?
Yes. Per-arch inplementations of bpf_int_jit_compile() make calls to
bpf_jit_binary_alloc() which does the randomized page offset with trap
instructions, and calls bpf_jit_binary_lock_ro() to make the memory
read-only at the end.
>> UDEREF and SMAP pointing at ret2usr+ROP is fine, but seems
>> "incomplete". Is there a good name for "reading user memory and
>> operating on a malicious structure"? It's a more narrow exploit
>> technique than ROP or executing userspace memory, but it's important
>> to cover.
>
> Yes, agree. That's what I did exploiting CVE-2017-2636: allocating struct
> skb_shared_info in the userspace memory with the destructor callback pointing to
> native_write_cr4() to disable SMEP. Is it what you mean?
Yup. Function pointers are the traditional target.
> I've added "ret2usr + type confusion". Do you like it?
>
> Kurt, that is CWE-843: Access of Resource Using Incompatible Type ('Type
> Confusion').
"type confusion" seems weird to me, but I haven't spent a lot of time
weighing the options of the naming of these things. "Overwriting a
function pointer" is the method, and the bug is "unexpectedly
accessing userspace memory from the kernel" (which is usually
"something overwrite a pointer").
> Kees, thanks again for such a cool feedback. The map is updated.
Very cool! Maybe also add an out-of-tree bubble for "Clang CFI", which
gives forward-edge protection for code-reuse...
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
