Date: Thu, 28 Jan 2016 15:34:32 -0800 From: Andy Lutomirski <luto@...capital.net> To: Kees Cook <keescook@...omium.org> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Andi Kleen <ak@...ux.intel.com> Subject: Re: [RFC PATCH 0/2] SROP Mitigation On Thu, Jan 28, 2016 at 3:10 PM, Kees Cook <keescook@...omium.org> wrote: > On Sun, Jan 24, 2016 at 12:12 AM, Scotty Bauer <sbauer@....utah.edu> wrote: >> Erik Bosman previously attempted to upstream some patches which mitigate SROP >> exploits in userland. Unfortunately he never pursued it further and they never >> got upstreamed. >> >> The previous patches can be seen here: >> https://lkml.org/lkml/2014/5/15/660 >> https://lkml.org/lkml/2014/5/15/661 >> https://lkml.org/lkml/2014/5/15/657 >> https://lkml.org/lkml/2014/5/15/858 >> >> In the discussion for those patches Andy Lutomirski and Andi Kleen had a few >> suggestions which are implemented in my patch series. >> >> Andy Lutomirski suggested that the per-process secret be xord and with the location >> on the stack where the cookie will reside, then hashed. I've taken this approach but >> have concerns about the safety and collision properties of the hash function I've used. >> >> Second, Andi Kleen was concerned that the previous patches broke the ABI. He suggested >> placing the cookie above the FP state. The code I'm submitting does that by placing the >> cookie in the padding above the FP state, or if no FP state is available above the >> padding for the sigframe. >> >> >> Below is an explanation of SROP stolen and slightly modified by me from Erik's patches. >> >> These patches are meant to make Sigreturn Oriented Programming (SROP) a much >> less attractive exploitation path. In Sigreturn Oriented Programming, an >> attacker causes a user-space program to call the sigreturn system call in order >> to get complete control control over the entire userspace context in one go. >> >> Previously attackers would have to search for ROP gadgets to get values into registers >> then call mprotect or mmap. If the ROP gadgets didnt exist well then they'd be in trouble. >> With SROP however one wouldn't have to search for ROP gadgets to get values into regs. >> The attacker would simply lay out the ucontext on the stack as they choose then >> SROP into the mprotect or mmap call. >> >> ( see: http://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf ) >> >> While mitigating SROP will probably not stop determined attackers from >> exploiting a program, as there's always the much more well-known Return >> Oriented Programming, we still think SROP's relative ease warrants mitigation, >> especially since the mitigation is so cheap. > > Cool! Thanks for bringing this series back! I quickly skimmed the > paper, so I apologize if I missed it, but have there been any public > exploits that used SROP, or is it considered to be "just" an > identified weakness in need of fixing? > > It seems performance overhead would be lost in the noise of catching > and processing signals, but have you done any benchmarks? > It would also be important to test DOSEMU and CRIU, both of which do interesting things with signal frames. --Andy
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.