[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPM5UJ2G_hWRYs-J3qsRV1E=aBZqPOacntT2ZA5zcNfZeibHzQ@mail.gmail.com>
Date: Thu, 26 Nov 2015 02:43:31 -0500
From: comex <comexk@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: On techniques for preventing commit_creds()
user-space abuse
On Wed, Nov 25, 2015 at 6:14 PM, Salva Peiró <speirofr@...il.com> wrote:
> - *Indirect jump*
> An attacker can perform an indirect jump to a kernel location that does
> the commit_creds() for him, but it complicates the task of the
> attacker. To prevent indirect calls check the rest of the stack trace.
The added complication of indirection is minimal, and checking the
frame pointer/return address chain on the stack would be far from
sufficient to prevent it: even if you had full control flow integrity
on returns (see e.g. RAP), if the attacker was already executing
arbitrary code, they could overwrite the whole stack to simulate a
call stack that would normally be allowed to call commit_creds and
won't crash on return, e.g. setuid returning to userland.
> - *Direct override*
> Another route to bypass would be to figure out the location of the
> process creds in memory, and perform the change directly in memory,
> but AFAIK SMAP and its ARM equivalent would deter this route.
SMEP (not SMAP) already makes it impossible to directly execute code
from userspace mapped addresses. SMAP prevents accessing those
addresses, but has no effect on kernel mapped addresses such as the
data structures containing credentials.
In general there's not much point trying to defend against an attacker
who is already running arbitrary code in kernel mode. Even executing
a ROP chain, once the attacker gets past any initial hurdles such as
stack pivoting, is pretty much game over (the possibility of it being
complicated to find gadgets with unusual instruction sequences, find a
large number of gadgets, or use a long chain of them /might/ make some
additional measures valuable, but not very - e.g. [1]); true code
execution generally makes working around any 'harassment' measures
trivial.
[1] http://vulnfactory.org/blog/2011/09/21/defeating-windows-8-rop-mitigation/
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.
