[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jK7O=h7zO4xw7YaVMxNK0sHgPOoncimKXM0pWiS=j4qVQ@mail.gmail.com>
Date: Tue, 3 May 2016 10:01:47 -0700
From: Kees Cook <keescook@...omium.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: BPF JIT spray attack - proof of concept code for modern kernel
On Mon, May 2, 2016 at 11:38 PM, Reshetova, Elena
<elena.reshetova@...el.com> wrote:
> Following Kees’s suggestion, I am posting here a link to the poc code that I
> did to show the need of further BPF JIT hardening:
> https://github.com/01org/jit-spray-poc-for-ksp
>
> This poc is based on the 2012 poc done by McAllister:
> https://github.com/kmcallister/alameda I have kept his commits untouched and
> only added mine on top that you can easily see what was modified.
>
> Some description of what it does and why it does work:
>
> The original 2012 poc stopped working after the address offset randomization
> for loading the BPF was added:
> http://lingrok.org/xref/linux-net-next/kernel/bpf/core.c#143
>
> This was due to the fact that McAllister code relied on random page guessing
> and was assuming filter to start at the page start. This approach clearly
> doesn’t work with new random address allocation since one would need to
> guess both page and offset and incorrect guess most commonly results in a
> full restart need for normal machine (after which filter address has changed
> and you don’t gain any knowledge).
>
>
>
> The main changes I did was to extend the filter size to spawn longer than 1
> full page (to make sure it would overrun into the next page) and then repeat
> the “get root payload” there in circles with enough of “nope” instructions
> to render it for most success. Also, when jumping to a new random page, I
> would try to execute the payload a number of times on the same page changing
> just an offset that is less than 10
> (https://github.com/01org/jit-spray-poc-for-ksp/blob/master/alameda.c#L325 )
> to make sure to walk through the “nopes” and invoke the payload if the page
> guess was correct.
>
>
>
> I have tried the poc on virtual machine with Ubuntu with 4.4 upstream kernel
> and it works quite well. It can still in some cases completely stall the
> machine that reboot is required, but it does reach its root goal in most of
> the cases.
>
> Also, please note that similarly as 2012 poc code, this is not a real exploit
> because it requires an “insecure ko” kernel module to actually make a jump,
> but it illustrates the need for further JIT hardening that Daniel is
> currently working now on.
This is great! Thanks for updating this research. It strongly helps
illustrate why instruction blinding is an important defense. I'm
looking forward to Daniel's work landing.
Thanks!
-Kees
--
Kees Cook
Chrome OS & Brillo Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
