From: Adam Zabrocki <pi3@pi3.com.pl>
To: Jann Horn <jannh@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
kernel list <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Bernd Edlinger <bernd.edlinger@hotmail.de>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH] signal: Extend exec_id to 64bits
Date: Fri, 3 Apr 2020 04:11:01 +0200 [thread overview]
Message-ID: <20200403021101.GA2608@pi3.com.pl> (raw)
In-Reply-To: <CAG48ez1dCPw9Dep-+GWn=SnHv1nVv4Npv1FpFxmomk6tmazB-g@mail.gmail.com>
On Thu, Apr 02, 2020 at 06:46:49AM +0200, Jann Horn wrote:
> On Wed, Apr 1, 2020 at 10:50 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Replace the 32bit exec_id with a 64bit exec_id to make it impossible
> > to wrap the exec_id counter. With care an attacker can cause exec_id
> > wrap and send arbitrary signals to a newly exec'd parent. This
> > bypasses the signal sending checks if the parent changes their
> > credentials during exec.
> >
> > The severity of this problem can been seen that in my limited testing
> > of a 32bit exec_id it can take as little as 19s to exec 65536 times.
> > Which means that it can take as little as 14 days to wrap a 32bit
> > exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7
> > days. Even my slower timing is in the uptime of a typical server.
>
> FYI, if you actually optimize this, it's more like 12s to exec 1048576
> times according to my test, which means ~14 hours for 2^32 executions
> (on a single core). That's on an i7-4790 (a Haswell desktop processor
> that was launched about six years ago, in 2014).
>
Yep, there are a few ways of optimizing it and I believe I've pointed it out
here:
https://www.openwall.com/lists/kernel-hardening/2020/03/31/11
Thanks for doing such tests :)
I've also modified your PoC to use 'sysenter' and 'syscall' instruction. Both
cases gave me an extra 4% speed bump (including a test for 64-bits
"fast_execve"). I've run it under Intel(R) Xeon(R) E-2176G CPU @ 3.70GHz
As you've proven, it is possible to be done in a matter of hours.
Thanks,
Adam
> Here's my test code:
>
> =============
> $ grep 'model name' /proc/cpuinfo | head -n1
> model name : Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
> $ cat build.sh
> #!/bin/sh
> set -e
> nasm -felf32 -o fast_execve.o fast_execve.asm
> ld -m elf_i386 -o fast_execve fast_execve.o
> gcc -o launch launch.c -Wall
> gcc -o finish finish.c -Wall
> $ cat fast_execve.asm
> bits 32
>
> section .text
> global _start
> _start:
> ; eax = argv[0]
> ; expected to be 8 hex digits, with 'a' meaning 0x0 and 'p' meaning 0xf
> mov eax, [esp+4]
>
> mov ebx, 0 ; loop counter
> hex_digit_loop:
> inc byte [eax+ebx]
> cmp byte [eax+ebx], 'a'+16
> jne next_exec
> mov byte [eax+ebx], 'a'
> inc ebx
> cmp ebx, 5 ;;;;;;;;;;;;;;;;;; this is N, where iteration_count=pow(16,N)
> jne hex_digit_loop
>
>
> ; reached pow(256,N) execs, get out
>
> ; first make the stack big again
> mov eax, 75 ; setrlimit (32-bit ABI)
> mov ebx, 3 ; RLIMIT_STACK
> mov ecx, stacklim
> int 0x80
>
> ; execute end helper
> mov ebx, 4 ; dirfd = 4
> jmp common_exec
>
> next_exec:
> mov ebx, 3 ; dirfd = 3
>
> common_exec: ; execveat() with file descriptor passed in as ebx
> mov ecx, nullval ; pathname = empty string
> lea edx, [esp+4] ; argv
> mov esi, 0 ; envp
> mov edi, 0x1000 ; flags = AT_EMPTY_PATH
> mov eax, 358 ; execveat (32-bit ABI)
> int 0x80
> int3
>
> nullval:
> dd 0
> stacklim:
> dd 0x02000000
> dd 0xffffffff
> $ cat launch.c
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <err.h>
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <sys/resource.h>
> int main(void) {
> close(3);
> close(4);
> if (open("fast_execve", O_PATH) != 3)
> err(1, "open fast_execve");
> if (open("finish", O_PATH) != 4)
> err(1, "open finish");
> char *argv[] = { "aaaaaaaa", NULL };
>
> struct rlimit lim;
> if (getrlimit(RLIMIT_STACK, &lim))
> err(1, "getrlimit");
> lim.rlim_cur = 0x4000;
> if (setrlimit(RLIMIT_STACK, &lim))
> err(1, "setrlimit");
>
> syscall(__NR_execveat, 3, "", argv, NULL, AT_EMPTY_PATH);
> }
> $ cat finish.c
> #include <stdlib.h>
> int main(void) {
> exit(0);
> }
> $ ./build.sh
> $ time ./launch
>
> real 0m12,075s
> user 0m0,905s
> sys 0m11,026s
> $
> =============
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
next prev parent reply other threads:[~2020-04-03 2:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 21:50 Curiosity around 'exec_id' and some problems associated with it Adam Zabrocki
2020-03-29 22:43 ` Kees Cook
2020-03-30 8:34 ` Oleg Nesterov
2020-03-31 4:29 ` Adam Zabrocki
2020-04-01 20:47 ` [PATCH] signal: Extend exec_id to 64bits Eric W. Biederman
2020-04-01 20:55 ` Linus Torvalds
2020-04-01 21:03 ` Eric W. Biederman
2020-04-01 23:37 ` Jann Horn
2020-04-01 23:51 ` Linus Torvalds
2020-04-01 23:55 ` Linus Torvalds
2020-04-02 1:35 ` Jann Horn
2020-04-02 2:05 ` Linus Torvalds
2020-04-02 13:11 ` Eric W. Biederman
2020-04-02 18:06 ` Linus Torvalds
2020-04-02 4:46 ` Jann Horn
2020-04-02 14:14 ` Eric W. Biederman
2020-04-03 2:11 ` Adam Zabrocki [this message]
2020-04-02 7:19 ` Kees Cook
2020-04-02 7:22 ` Bernd Edlinger
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=20200403021101.GA2608@pi3.com.pl \
--to=pi3@pi3.com.pl \
--cc=akpm@linux-foundation.org \
--cc=bernd.edlinger@hotmail.de \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).