From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>
Cc: mtk.manpages@gmail.com, Tycho Andersen <tycho@tycho.pizza>,
Sargun Dhillon <sargun@sargun.me>,
Christian Brauner <christian@brauner.io>,
Daniel Borkmann <daniel@iogearbox.net>,
Giuseppe Scrivano <gscrivan@redhat.com>,
Song Liu <songliubraving@fb.com>,
Robert Sesek <rsesek@google.com>,
Containers <containers@lists.linux-foundation.org>,
linux-man <linux-man@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Alexei Starovoitov <ast@kernel.org>,
Will Drewry <wad@chromium.org>, bpf <bpf@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: For review: seccomp_user_notif(2) manual page [v2]
Date: Thu, 29 Oct 2020 15:19:45 +0100 [thread overview]
Message-ID: <0de41eb1-e1fd-85da-61b7-fac4e3006726@gmail.com> (raw)
In-Reply-To: <CAG48ez0fBE6AJfWh0in=WKkgt98y=KjAen=SQPyTYtvsUbF1yA@mail.gmail.com>
Hello Jann,
On 10/29/20 2:42 AM, Jann Horn wrote:
> On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> static bool
>> getTargetPathname(struct seccomp_notif *req, int notifyFd,
>> char *path, size_t len)
>> {
>> char procMemPath[PATH_MAX];
>>
>> snprintf(procMemPath, sizeof(procMemPath), "/proc/%d/mem", req->pid);
>>
>> int procMemFd = open(procMemPath, O_RDONLY);
>> if (procMemFd == -1)
>> errExit("\tS: open");
>>
>> /* Check that the process whose info we are accessing is still alive.
>> If the SECCOMP_IOCTL_NOTIF_ID_VALID operation (performed
>> in checkNotificationIdIsValid()) succeeds, we know that the
>> /proc/PID/mem file descriptor that we opened corresponds to the
>> process for which we received a notification. If that process
>> subsequently terminates, then read() on that file descriptor
>> will return 0 (EOF). */
>>
>> checkNotificationIdIsValid(notifyFd, req->id);
>>
>> /* Read bytes at the location containing the pathname argument
>> (i.e., the first argument) of the mkdir(2) call */
>>
>> ssize_t nread = pread(procMemFd, path, len, req->data.args[0]);
>> if (nread == -1)
>> errExit("pread");
>
> As discussed at
> <https://lore.kernel.org/r/CAG48ez0m4Y24ZBZCh+Tf4ORMm9_q4n7VOzpGjwGF7_Fe8EQH=Q@mail.gmail.com>,
> we need to re-check checkNotificationIdIsValid() after reading remote
> memory but before using the read value in any way. Otherwise, the
> syscall could in the meantime get interrupted by a signal handler, the
> signal handler could return, and then the function that performed the
> syscall could free() allocations or return (thereby freeing buffers on
> the stack).
>
> In essence, this pread() is (unavoidably) a potential use-after-free
> read; and to make that not have any security impact, we need to check
> whether UAF read occurred before using the read value. This should
> probably be called out elsewhere in the manpage, too...
Thanks very much for pointing me at this!
So, I want to conform that the fix to the code is as simple as
adding a check following the pread() call, something like:
[[
ssize_t nread = pread(procMemFd, path, len, req->data.args[argNum]);
if (nread == -1)
errExit("Supervisor: pread");
if (nread == 0) {
fprintf(stderr, "\tS: pread() of /proc/PID/mem "
"returned 0 (EOF)\n");
exit(EXIT_FAILURE);
}
if (close(procMemFd) == -1)
errExit("Supervisor: close-/proc/PID/mem");
+ /* Once again check that the notification ID is still valid. The
+ case we are particularly concerned about here is that just
+ before we fetched the pathname, the target's blocked system
+ call was interrupted by a signal handler, and after the handler
+ returned, the target carried on execution (past the interrupted
+ system call). In that case, we have no guarantees about what we
+ are reading, since the target's memory may have been arbitrarily
+ changed by subsequent operations. */
+
+ if (!notificationIdIsValid(notifyFd, req->id, "post-open"))
+ return false;
+
/* We have no guarantees about what was in the memory of the target
process. We therefore treat the buffer returned by pread() as
untrusted input. The buffer should be terminated by a null byte;
if not, then we will trigger an error for the target process. */
if (strnlen(path, nread) < nread)
return true;
]]
> Now, of course, **reading** is the easy case. The difficult case is if
> we have to **write** to the remote process... because then we can't
> play games like that. If we write data to a freed pointer, we're
> screwed, that's it. (And for somewhat unrelated bonus fun, consider
> that /proc/$pid/mem is originally intended for process debugging,
> including installing breakpoints, and will therefore happily write
> over "readonly" private mappings, such as typical mappings of
> executable code.)
>
> So, uuuuh... I guess if anyone wants to actually write memory back to
> the target process, we'd better come up with some dedicated API for
> that, using an ioctl on the seccomp fd that magically freezes the
> target process inside the syscall while writing to its memory, or
> something like that? And until then, the manpage should have a big fat
> warning that writing to the target's memory is simply not possible
> (safely).
>
>> if (nread == 0) {
>> fprintf(stderr, "\tS: pread() of /proc/PID/mem "
>> "returned 0 (EOF)\n");
>> exit(EXIT_FAILURE);
>> }
> .
I'll think over some changes to the text of the manual page.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2020-10-29 14:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 9:55 For review: seccomp_user_notif(2) manual page [v2] Michael Kerrisk (man-pages)
2020-10-26 13:54 ` Tycho Andersen
2020-10-26 14:30 ` Michael Kerrisk (man-pages)
2020-10-26 14:32 ` Tycho Andersen
2020-10-29 1:42 ` Jann Horn
[not found] ` <20201029020438.GA25673@cisco>
2020-10-29 4:43 ` Jann Horn
2020-10-29 14:19 ` Michael Kerrisk (man-pages) [this message]
2020-10-30 19:14 ` Jann Horn
2020-10-31 8:31 ` Michael Kerrisk (man-pages)
2020-11-02 13:49 ` Jann Horn
2020-10-29 19:14 ` Michael Kerrisk (man-pages)
2020-10-30 19:20 ` Jann Horn
2020-10-31 8:51 ` Michael Kerrisk (man-pages)
2020-11-02 14:13 ` Jann Horn
2020-10-29 8:53 ` Sargun Dhillon
2020-10-29 20:37 ` Michael Kerrisk (man-pages)
2020-10-30 20:27 ` Sargun Dhillon
2020-10-31 16:27 ` Michael Kerrisk (man-pages)
2020-11-02 8:07 ` Sargun Dhillon
2020-11-02 19:45 ` Michael Kerrisk (man-pages)
2020-11-02 19:49 ` Sargun Dhillon
2020-11-02 20:04 ` Jann Horn
2020-10-29 15:26 ` Christian Brauner
2020-10-29 19:53 ` Michael Kerrisk (man-pages)
2020-10-30 19:24 ` Jann Horn
2020-10-30 20:07 ` Michael Kerrisk (man-pages)
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=0de41eb1-e1fd-85da-61b7-fac4e3006726@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christian@brauner.io \
--cc=containers@lists.linux-foundation.org \
--cc=cyphar@cyphar.com \
--cc=daniel@iogearbox.net \
--cc=gscrivan@redhat.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=rsesek@google.com \
--cc=sargun@sargun.me \
--cc=songliubraving@fb.com \
--cc=tycho@tycho.pizza \
--cc=wad@chromium.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).