From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 492B3C2D0A8 for ; Wed, 23 Sep 2020 18:01:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9B4CE2075B for ; Wed, 23 Sep 2020 18:01:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Y3L1gNgA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B4CE2075B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=openwall.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Mime-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pUVNQYRJu6fBnkK1mgXDUD9AR7HUn9AHIzQGHQzZbBc=; b=Y3L1gNgA7YbGB3IgJgsarOc/t 3YrfRKHsG/RJ9rKROI2huZV3ocCzOoHWxvsIa5snDEv2uj/LizQ8fkKAgULdNAyOlhg780b9lqzFc NAQQtRDpWoCVVUE+bKy1h4vvT/n2AztUJXu7xDaWC9NRo5XRpsVwNIAeD1HX75aWgMqW477oH68ZX A82hMBmvEL9E1zghvjKhAgZLRFeCacN0KCthmvvxgSurQiTRq227JEAU9HKvdDayhKlx6Z3R2+ezi qGBKk5aXZTvtemaToVCZZtR4JwVbe5k+WzkHhMLMNwUF53qHn2zyB+g5cuBqmRPL0dwzCVlR11y4w hWp8mDVhw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL93x-0005eE-UF; Wed, 23 Sep 2020 18:00:18 +0000 Received: from mother.openwall.net ([195.42.179.200]) by merlin.infradead.org with smtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL93u-0005dP-KE for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 18:00:16 +0000 Received: (qmail 18029 invoked from network); 23 Sep 2020 18:00:12 -0000 Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 23 Sep 2020 18:00:12 -0000 Received: by pvt.openwall.com (Postfix, from userid 503) id 59151AB844; Wed, 23 Sep 2020 20:00:07 +0200 (CEST) Date: Wed, 23 Sep 2020 20:00:07 +0200 From: Solar Designer To: Pavel Machek Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Message-ID: <20200923180007.GA8646@openwall.com> References: <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923081426.GA30279@amd> <20200923091456.GA6177@openwall.com> <20200923141102.GA7142@openwall.com> <20200923151835.GA32555@duo.ucw.cz> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200923151835.GA32555@duo.ucw.cz> User-Agent: Mutt/1.4.2.3i X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_140014_966548_436B3EFA X-CRM114-Status: GOOD ( 18.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, mark.rutland@arm.com, Rich Felker , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, madvenka@linux.microsoft.com, mic@digikod.net, linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM, luto@kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 23, 2020 at 05:18:35PM +0200, Pavel Machek wrote: > > It sure does make sense to combine ret2libc/ROP to mprotect() with one's > > own injected shellcode. Compared to doing everything from ROP, this is > > easier and more reliable across versions/builds if the desired > > payload > > Ok, so this starts to be a bit confusing. > > I thought W^X is to protect from attackers that have overflowed buffer > somewhere, but can not to do arbitrary syscalls, yet. > > You are saying that there's important class of attackers that can do > some syscalls but not arbitrary ones. They might be able to do many, most, or all arbitrary syscalls via ret2libc or such. The crucial detail is that each time they do that, they risk incompatibility with the given target system (version, build, maybe ASLR if gadgets from multiple libraries are involved). By using mprotect(), they only take this risk once (need to get the address of an mprotect() gadget and of what to change protections on right), and then they can invoke multiple syscalls from their shellcode more reliably. So for doing a lot of work, mprotect() combined with injected code can be easier and more reliable. It is also an extra option an attacker can use, in addition to doing everything via borrowed code. More flexibility for the attacker means the attacker may choose whichever approach works better in a given case (or try several). I am embarrassed for not thinking/recalling this when I first posted earlier today. It's actually obvious. I'm just getting old and rusty. > I'd like to see definition of that attacker (and perhaps description > of the system the protection is expected to be useful on -- if it is > not close to common Linux distros). There's nothing unusual about that attacker and the system. A couple of other things Brad kindly pointed out: SELinux already has similar protections (execmem, execmod): http://lkml.iu.edu/hypermail/linux/kernel/0508.2/0194.html https://danwalsh.livejournal.com/6117.html PaX MPROTECT is implemented in a way or at a layer that covers ptrace() abuse that I mentioned. (At least that's how I understood Brad.) Alexander P.S. Meanwhile, Twitter locked my account "for security purposes". Fun. I'll just let it be for now. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel