From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754210AbcCIWCs (ORCPT ); Wed, 9 Mar 2016 17:02:48 -0500 Received: from mailhub.eng.utah.edu ([155.98.110.27]:41193 "EHLO mailhub.eng.utah.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934224AbcCIWCW (ORCPT ); Wed, 9 Mar 2016 17:02:22 -0500 Subject: Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies To: Andy Lutomirski References: <1457470075-4586-1-git-send-email-sbauer@eng.utah.edu> <56DF48EF.2080305@eng.utah.edu> Cc: "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , X86 ML , wmealing@redhat.com, Andi Kleen , Abhiram Balasubramanian From: Scotty Bauer Message-ID: <56E09D5C.5090908@eng.utah.edu> Date: Wed, 9 Mar 2016 15:02:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-UCE-Score: -1.9 (-) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/08/2016 02:57 PM, Andy Lutomirski wrote: > On Tue, Mar 8, 2016 at 1:49 PM, Scotty Bauer wrote: >> >> >> On 03/08/2016 01:58 PM, Andy Lutomirski wrote: >>> On Tue, Mar 8, 2016 at 12:47 PM, Scott Bauer 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 > I've been thinking about this a little bit more. I don't think zeroing the frame is a proper mitigation. If an attacker has the ability to write a lot of data to the stack they could simply create a new fake signal frame above the current frame. In this scenario the kernel would zero the current frame then return somewhere attacker controlled, where the attackers payload would then use the next signal frame above the zero'd frame. So while this zeroing would solve a stricter case where an attacker has to keep reusing the same frame over and over, perhaps to avoid overwriting a stack cookie, It doesn't solve every case. Thanks for the good ideas. From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <1457470075-4586-1-git-send-email-sbauer@eng.utah.edu> <56DF48EF.2080305@eng.utah.edu> From: Scotty Bauer Message-ID: <56E09D5C.5090908@eng.utah.edu> Date: Wed, 9 Mar 2016 15:02:04 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , X86 ML , wmealing@redhat.com, Andi Kleen , Abhiram Balasubramanian List-ID: On 03/08/2016 02:57 PM, Andy Lutomirski wrote: > On Tue, Mar 8, 2016 at 1:49 PM, Scotty Bauer wrote: >> >> >> On 03/08/2016 01:58 PM, Andy Lutomirski wrote: >>> On Tue, Mar 8, 2016 at 12:47 PM, Scott Bauer 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 > I've been thinking about this a little bit more. I don't think zeroing the frame is a proper mitigation. If an attacker has the ability to write a lot of data to the stack they could simply create a new fake signal frame above the current frame. In this scenario the kernel would zero the current frame then return somewhere attacker controlled, where the attackers payload would then use the next signal frame above the zero'd frame. So while this zeroing would solve a stricter case where an attacker has to keep reusing the same frame over and over, perhaps to avoid overwriting a stack cookie, It doesn't solve every case. Thanks for the good ideas.