From: Solar Designer <solar@openwall.com> To: Pavel Machek <pavel@ucw.cz> Cc: madvenka@linux.microsoft.com, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, oleg@redhat.com, x86@kernel.org, luto@kernel.org, David.Laight@ACULAB.COM, fweimer@redhat.com, mark.rutland@arm.com, mic@digikod.net, Rich Felker <dalias@libc.org> Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Date: Wed, 23 Sep 2020 20:00:07 +0200 [thread overview] Message-ID: <20200923180007.GA8646@openwall.com> (raw) In-Reply-To: <20200923151835.GA32555@duo.ucw.cz> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Solar Designer <solar@openwall.com> To: Pavel Machek <pavel@ucw.cz> Cc: fweimer@redhat.com, mark.rutland@arm.com, Rich Felker <dalias@libc.org>, 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 Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Date: Wed, 23 Sep 2020 20:00:07 +0200 [thread overview] Message-ID: <20200923180007.GA8646@openwall.com> (raw) In-Reply-To: <20200923151835.GA32555@duo.ucw.cz> 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
next prev parent reply other threads:[~2020-09-23 18:00 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <210d7cd762d5307c2aa1676705b392bd445f1baa> 2020-09-16 15:08 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor madvenka 2020-09-16 15:08 ` madvenka 2020-09-16 15:08 ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka 2020-09-16 15:08 ` madvenka 2020-09-16 15:08 ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka 2020-09-16 15:08 ` madvenka 2020-09-17 1:10 ` kernel test robot 2020-09-17 3:04 ` kernel test robot 2020-09-16 15:08 ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka 2020-09-16 15:08 ` madvenka 2020-09-16 15:08 ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka 2020-09-16 15:08 ` madvenka 2020-09-17 1:04 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Florian Weimer 2020-09-17 1:04 ` Florian Weimer 2020-09-17 1:04 ` Florian Weimer 2020-09-17 15:36 ` Madhavan T. Venkataraman 2020-09-17 15:36 ` Madhavan T. Venkataraman 2020-09-17 15:57 ` Madhavan T. Venkataraman 2020-09-17 15:57 ` Madhavan T. Venkataraman 2020-09-17 16:01 ` Florian Weimer 2020-09-17 16:01 ` Florian Weimer 2020-09-17 16:01 ` Florian Weimer 2020-09-23 1:46 ` Arvind Sankar 2020-09-23 1:46 ` Arvind Sankar 2020-09-23 9:11 ` Arvind Sankar 2020-09-23 9:11 ` Arvind Sankar 2020-09-23 19:17 ` Madhavan T. Venkataraman 2020-09-23 19:17 ` Madhavan T. Venkataraman 2020-09-23 19:51 ` Arvind Sankar 2020-09-23 19:51 ` Arvind Sankar 2020-09-23 23:51 ` Madhavan T. Venkataraman 2020-09-23 23:51 ` Madhavan T. Venkataraman 2020-09-24 20:23 ` Madhavan T. Venkataraman 2020-09-24 20:23 ` Madhavan T. Venkataraman 2020-09-24 20:52 ` Florian Weimer 2020-09-24 20:52 ` Florian Weimer 2020-09-24 20:52 ` Florian Weimer 2020-09-25 22:22 ` Madhavan T. Venkataraman 2020-09-25 22:22 ` Madhavan T. Venkataraman 2020-09-27 18:25 ` Madhavan T. Venkataraman 2020-09-27 18:25 ` Madhavan T. Venkataraman 2020-10-03 9:43 ` Jay K 2020-10-03 9:43 ` Jay K 2020-09-24 22:13 ` Pavel Machek 2020-09-24 22:13 ` Pavel Machek 2020-09-24 23:43 ` Arvind Sankar 2020-09-24 23:43 ` Arvind Sankar 2020-09-25 22:44 ` Madhavan T. Venkataraman 2020-09-25 22:44 ` Madhavan T. Venkataraman 2020-09-26 15:55 ` Arvind Sankar 2020-09-26 15:55 ` Arvind Sankar 2020-09-27 17:59 ` Madhavan T. Venkataraman 2020-09-27 17:59 ` Madhavan T. Venkataraman 2020-09-23 2:50 ` Jay K 2020-09-23 2:50 ` Jay K 2020-09-22 21:53 ` madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:53 ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:53 ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka 2020-09-22 21:53 ` madvenka 2020-09-23 13:40 ` kernel test robot 2020-09-22 21:53 ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:53 ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:54 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Madhavan T. Venkataraman 2020-09-22 21:54 ` Madhavan T. Venkataraman 2020-09-23 8:14 ` Pavel Machek 2020-09-23 8:14 ` Pavel Machek 2020-09-23 9:14 ` Solar Designer 2020-09-23 9:14 ` Solar Designer 2020-09-23 14:11 ` Solar Designer 2020-09-23 14:11 ` Solar Designer 2020-09-23 15:18 ` Pavel Machek 2020-09-23 15:18 ` Pavel Machek 2020-09-23 18:00 ` Solar Designer [this message] 2020-09-23 18:00 ` Solar Designer 2020-09-23 18:21 ` Solar Designer 2020-09-23 18:21 ` Solar Designer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 18:09 ` Andy Lutomirski 2020-09-23 18:09 ` Andy Lutomirski 2020-09-23 18:11 ` Solar Designer 2020-09-23 18:11 ` Solar Designer 2020-09-23 18:49 ` Arvind Sankar 2020-09-23 18:49 ` Arvind Sankar 2020-09-23 23:53 ` Madhavan T. Venkataraman 2020-09-23 23:53 ` Madhavan T. Venkataraman 2020-09-23 19:41 ` Madhavan T. Venkataraman 2020-09-23 19:41 ` Madhavan T. Venkataraman 2020-09-23 18:10 ` James Morris 2020-09-23 18:10 ` James Morris 2020-09-23 18:32 ` Madhavan T. Venkataraman 2020-09-23 18:32 ` Madhavan T. Venkataraman 2020-09-23 8:42 ` Pavel Machek 2020-09-23 8:42 ` Pavel Machek 2020-09-23 18:56 ` Madhavan T. Venkataraman 2020-09-23 18:56 ` Madhavan T. Venkataraman 2020-09-23 20:51 ` Pavel Machek 2020-09-23 20:51 ` Pavel Machek 2020-09-23 23:04 ` Madhavan T. Venkataraman 2020-09-23 23:04 ` Madhavan T. Venkataraman 2020-09-24 16:44 ` Mickaël Salaün 2020-09-24 16:44 ` Mickaël Salaün 2020-09-24 22:05 ` Pavel Machek 2020-09-24 22:05 ` Pavel Machek 2020-09-25 10:12 ` Mickaël Salaün 2020-09-25 10:12 ` Mickaël Salaün
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200923180007.GA8646@openwall.com \ --to=solar@openwall.com \ --cc=David.Laight@ACULAB.COM \ --cc=dalias@libc.org \ --cc=fweimer@redhat.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@kernel.org \ --cc=madvenka@linux.microsoft.com \ --cc=mark.rutland@arm.com \ --cc=mic@digikod.net \ --cc=oleg@redhat.com \ --cc=pavel@ucw.cz \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.