From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86813 invoked by alias); 31 May 2019 17:06:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 86805 invoked by uid 89); 31 May 2019 17:06:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Brand, H*f:sk:XpFRPnt, H*i:sk:XpFRPnt, HX-Languages-Length:3189 X-HELO: mail-pg1-f193.google.com Received: from mail-pg1-f193.google.com (HELO mail-pg1-f193.google.com) (209.85.215.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 17:06:08 +0000 Received: by mail-pg1-f193.google.com with SMTP id z3so4367583pgp.8 for ; Fri, 31 May 2019 10:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho-ws.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eqW208lmlN1FGwKl7axbBvjMXSZyuJ5zqYjalMFmpNs=; b=aheLA2+ehQ+MY0QiTVDyNGrl2RgR6c+Q04r5iCbT9ucWeq/WVzS1gbSi5RkxNCB47r sJRj1GojGSTOszyX1MJGG0nocrvLACUXj3yTCuCfHD7LyOSeFFyeiM9wm6SDOFdH1dEa ufsW4ObLW5mn2QOU7LoZFfIRvNhNbzk30vi4cM6YjswLRnSjd4tRiNiz4kaaHNmiMWGZ AAoJ02vX+E5P9Yxqsr2TzRC+tDkaprkGCu2w0VV544bEpA7TA+Lxx+Po9aBuyfxc3fKS 14xSqgcdQorkkgowCWQm5CbL4gZaPugsL6YVADgef2lM11N6r38RBQbXt+qqvLFKiXtG xXtw== Return-Path: Received: from cisco ([2601:280:4:b795:840:fa90:7243:7032]) by smtp.gmail.com with ESMTPSA id g15sm9883296pfm.119.2019.05.31.10.06.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 31 May 2019 10:06:05 -0700 (PDT) Date: Fri, 31 May 2019 17:06:00 -0000 From: Tycho Andersen To: Mark Brand Cc: Andrew Pinski , GCC Mailing List , Kernel Hardening Subject: Re: unrecognizable insn generated in plugin? Message-ID: <20190531170558.GD5739@cisco> References: <20190530170033.GA5739@cisco> <20190530192606.GB5739@cisco> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-05/txt/msg00282.txt.bz2 On Fri, May 31, 2019 at 05:43:44PM +0200, Mark Brand wrote: > On Thu, May 30, 2019 at 9:26 PM Tycho Andersen wrote: > > > > Hi Andrew, > > > > On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote: > > > On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote: > > > > > > > > Hi all, > > > > > > > > I've been trying to implement an idea Andy suggested recently for > > > > preventing some kinds of ROP attacks. The discussion of the idea is > > > > here: > > > > https://lore.kernel.org/linux-mm/DFA69954-3F0F-4B79-A9B5-893D33D87E51@amacapital.net/ > > > > > > > Hi Tycho, > > I realise this is maybe not relevant to the topic of fixing the > plugin; but I'm struggling to understand what this is intending to > protect against. > > The idea seems to be to make sure that restored rbp, rsp values are > "close" to the current rbp, rsp values? The only scenario I can see > this providing any benefit is if an attacker can only corrupt a saved > stack/frame pointer, which seems like such an unlikely situation that > it's not really worth adding any complexity to defend against. > An attacker who has control of rip can surely get a controlled value > into rsp in various ways; Yes, if you already have control of rip this doesn't help you. > a quick scan of the current Ubuntu 18.04 > kernel image offers the following sequence (which shows up > everywhere): > > lea rsp, qword ptr [r10 - 8] > ret > > I'd assume that it's not tremendously difficult for an attacker to > chain to this without needing to previously pivot out the stack > pointer, assuming that at the point at which they gain control of rip > they have control over some state somewhere. If you could explain the > exact attack scenario that you have in mind then perhaps I could > provide a better explanation of how one might bypass it. The core bit that's important here is the writes to rsp/rbp, not the fact that they're pop instructions. The insight is that we know how the thread's stack should be aligned, and so any value that's written to these registers outside of that alignment (during "normal" execution) is a bug. The idea is that a ROP attack requires a payload to be injected somewhere so that it can return to this payload and execute this attack. This is most probably done via some allocation elsewhere (add_key() or unreceived data or whatever) since as you note, the stack should be mostly well protected. So then, if we don't allow anyone to write anything that's not on the stack to rsp/rbp, in principle we should be safe from ROP attacks where the payload is elsewhere. As you note, preventing bad "pop rpb" instructions is not enough, nor is preventing bad "pop rsp", as Andy initially proposed. We need to prevent all bad writes to these registers, including the sequence you mentioned, and presumably others. So there would need to be a lot more matching and checks inserted, and maybe it would ultimately be slow. Right now I just wanted to play with it for a bit to see if I can get it to work at all even in one case :) Am I thinking about this wrong? Any discussion is welcome, thanks! Tycho