Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1682652

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

From Kees Cook <keescook@chromium.org>
Newsgroups linux.kernel
Subject Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation
Date 2017-07-06 21:00 +0200
Message-ID <u0kal-RF-7@gated-at.bofh.it> (permalink)
References <u02Qa-5ct-1@gated-at.bofh.it> <u0fkl-4Ys-13@gated-at.bofh.it> <u0hct-7dv-15@gated-at.bofh.it> <u0hm9-7mU-13@gated-at.bofh.it> <u0jei-gY-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Jul 6, 2017 at 10:53 AM, Rik van Riel <riel@redhat.com> wrote:
> On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote:
>> On Thu, 6 Jul 2017, Kees Cook wrote:
>> > That requires a series of arbitrary reads. This is protecting
>> > against
>> > attacks that use an adjacent slab object write overflow to write
>> > the
>> > freelist pointer. This internal structure is very reliable, and has
>> > been the basis of freelist attacks against the kernel for a decade.
>>
>> These reads are not arbitrary. You can usually calculate the page struct
>> address easily from the address and then do a couple of loads to get
>> there.
>>
>> Ok so you get rid of the old attacks because we did not have that
>> hardening in effect when they designed their approaches?
>
> The hardening protects against situations where
> people do not have arbitrary code execution and
> memory read access in the kernel, with the goal
> of protecting people from acquiring those abilities.

Right. This is about blocking the escalation of attack capability. For
slab object overflow flaws, there are mainly two exploitation methods:
adjacent allocated object overwrite and adjacent freed object
overwrite (i.e. a freelist pointer overwrite). The first attack
depends heavily on which slab cache (and therefore which structures)
has been exposed by the bug. It's a very narrow and specific attack
method. The freelist attack is entirely general purpose since it
provides a reliable way to gain arbitrary write capabilities.
Protecting against that attack greatly narrows the options for an
attacker which makes attacks more expensive to create and possibly
less reliable (and reliability is crucial to successful attacks).

>> > It is a probabilistic defense, but then so is the stack protector.
>> > This is a similar defense; while not perfect it makes the class of
>> > attack much more difficult to mount.
>>
>> Na I am not convinced of the "much more difficult". Maybe they will just
>> have to upgrade their approaches to fetch the proper values to
>> decode.
>
> Easier said than done. Most of the time there is an
> unpatched vulnerability outstanding, there is only
> one known issue, before the kernel is updated by the
> user, to a version that does not have that issue.
>
> Bypassing kernel hardening typically requires the
> use of multiple vulnerabilities, and the absence of
> roadblocks (like hardening) that make a type of
> vulnerability exploitable.
>
> Between usercopy hardening, and these slub freelist
> canaries (which is what they effectively are), several
> classes of exploits are no longer usable.

Yup. I've been thinking of this patch kind of like glibc's PTR_MANGLE feature.

-Kees

-- 
Kees Cook
Pixel Security

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook <keescook@chromium.org> - 2017-07-06 02:30 +0200
  Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Christoph Lameter <cl@linux.com> - 2017-07-06 15:50 +0200
    Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook <keescook@chromium.org> - 2017-07-06 17:50 +0200
      Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Christoph Lameter <cl@linux.com> - 2017-07-06 18:00 +0200
        Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list  pointer obfuscation Daniel Micay <danielmicay@gmail.com> - 2017-07-06 18:20 +0200
        Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Rik van Riel <riel@redhat.com> - 2017-07-06 20:00 +0200
          Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook <keescook@chromium.org> - 2017-07-06 21:00 +0200
            Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Christoph Lameter <cl@linux.com> - 2017-07-07 16:00 +0200
              Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook <keescook@chromium.org> - 2017-07-07 19:00 +0200
                Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Christoph Lameter <cl@linux.com> - 2017-07-07 19:10 +0200
                Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation Kees Cook <keescook@chromium.org> - 2017-07-07 20:50 +0200

csiph-web