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

Groups > linux.kernel > #1353441

Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies

Show all headers | View raw

On 03/08/2016 02:57 PM, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 1:49 PM, Scotty Bauer <sbauer@eng.utah.edu> wrote:
>>
>>
>> On 03/08/2016 01:58 PM, Andy Lutomirski wrote:
>>> On Tue, Mar 8, 2016 at 12:47 PM, Scott Bauer <sbauer@eng.utah.edu> wrote:
>>>> This patch adds a per-process secret to the task struct which
>>>> will be used during signal delivery and during a sigreturn.
>>>> Also, logic is added in signal.c to generate, place, extract,
>>>> clear and verify the signal cookie.
>>>>
>>>
>>> Potentially silly question: it's been a while since I read the SROP
>>> paper, but would the technique be effectively mitigated if sigreturn
>>> were to zero out the whole signal frame before returning to user mode?
>>>
>>
>> I don't know if I fully understand your question, but I'll respond anyway.
>>
>> SROP is possible because the kernel doesn't know whether or not the
>> incoming sigreturn syscall is in response from a legitimate signal that
>> the kernel had previously delivered and the program handled. So essentially
>> these patches are an attempt to give the kernel a way to verify whether or
>> not the the incoming sigreturn is a valid response or a exploit trying to
>> hijack control of the user program.
>>
> 
> I got that part, but I thought that the interesting SROP bit was using
> sigreturn to return back to a frame where you could just repeat the
> sigreturn a bunch of times to compute things and do other evil.  I'm
> wondering whether zeroing the whole frame would make SROP much less
> interesting to an attacker.
> 
> --Andy
> 

Ah, I see now. I believe that would work for subsequent sigreturns but not
the first.

The paper did talk about actually ROP'ing using sigreturns but I never really
liked that idea. I think they missed the obvious reason an attacker would use
SROP. The reason an attacker would use is it gives you an extremely easy
way to get values into registers.. you just set them to what you want them to be
then sigret. Previously an attacker would have to find gadgets and ROP around until
the registers are in a good enough state to do what ever they want. 

I mostly designed the patches with that in mind instead of actually ROPing with sigret.

I can certainly add zeroing the stack frame, but not sure if there would be a performance
regression in doing so or if it's really relevant if we keep the cookie.

 

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

Thread

[PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies Scott Bauer <sbauer@eng.utah.edu> - 2016-03-08 21:50 +0100
  Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Andy Lutomirski <luto@amacapital.net> - 2016-03-08 22:00 +0100
    Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Andy Lutomirski <luto@amacapital.net> - 2016-03-08 23:00 +0100
      Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-08 23:10 +0100
      Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-09 23:10 +0100
    Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-08 23:00 +0100
  Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code  for signal cookies kbuild test robot <lkp@intel.com> - 2016-03-08 22:10 +0100
  Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code  for signal cookies Ingo Molnar <mingo@kernel.org> - 2016-03-09 09:40 +0100
    Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for  signal cookies Scotty Bauer <sbauer@eng.utah.edu> - 2016-03-09 23:10 +0100
      Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code  for signal cookies Jonathan Corbet <corbet@lwn.net> - 2016-03-09 23:30 +0100
        Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code  for signal cookies Ingo Molnar <mingo@kernel.org> - 2016-03-10 10:50 +0100

csiph-web