[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJpd-bFsdK-hqMwr8tirr3EYVaZE2e55sH5ZY3vjYkuTERZsMg@mail.gmail.com>
Date: Thu, 26 Nov 2015 16:32:02 +0100
From: Salva Peiró <speirofr@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: On techniques for preventing commit_creds()
user-space abuse
On Thu, Nov 26, 2015 at 8:43 AM, comex <comexk@...il.com> wrote:
> 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/
>
Thanks for explaining the flaws I was wondering why it wasn't done.
Implementing such a thing is pointless, since by the time the attacker
is executing code he can already bypass the protections as shown in [1].
Content of type "text/html" skipped
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.
