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. ); true code > execution generally makes working around any 'harassment' measures > trivial. > >  > 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 . 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.