From: Jann Horn <firstname.lastname@example.org>
To: Andrew Morton <email@example.com>
Cc: Kees Cook <firstname.lastname@example.org>,
Alexey Dobriyan <email@example.com>,
Ken Chen <firstname.lastname@example.org>,
kernel list <email@example.com>,
firstname.lastname@example.org, Will Deacon <email@example.com>,
Laura Abbott <firstname.lastname@example.org>,
Andy Lutomirski <email@example.com>,
firstname.lastname@example.org, Catalin Marinas <email@example.com>,
Josh Poimboeuf <firstname.lastname@example.org>,
Thomas Gleixner <email@example.com>,
Ingo Molnar <firstname.lastname@example.org>, "H . Peter Anvin" <email@example.com>,
Linux API <firstname.lastname@example.org>
Subject: Re: [PATCH resend] proc: restrict kernel stack dumps to root
Date: Fri, 28 Sep 2018 00:39:16 +0200 [thread overview]
Message-ID: <CAG48ez3CSRuY3g+ug+PaM2ivc2n_fJQuP9U9VKv8JLELtBoLbA@mail.gmail.com> (raw)
On Fri, Sep 28, 2018 at 12:29 AM Andrew Morton
> On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn <email@example.com> wrote:
> > Restrict the ability to inspect kernel stacks of arbitrary tasks to root
> > in order to prevent a local attacker from exploiting racy stack unwinding
> > to leak kernel task stack contents.
> > See the added comment for a longer rationale.
> > There don't seem to be any users of this userspace API that can't
> > gracefully bail out if reading from the file fails. Therefore, I believe
> > that this change is unlikely to break things.
> > In the case that this patch does end up needing a revert, the next-best
> > solution might be to fake a single-entry stack based on wchan.
> > Fixes: 2ec220e27f50 ("proc: add /proc/*/stack")
> > Cc: firstname.lastname@example.org
> > Signed-off-by: Jann Horn <email@example.com>
> It's a bit worrisome cc'ing stable on a patch which might need a revert.
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -407,6 +407,20 @@ static int proc_pid_stack(struct seq_file *m, struct pid_namespace *ns,
> > unsigned long *entries;
> > int err;
> > + /*
> > + * The ability to racily run the kernel stack unwinder on a running task
> > + * and then observe the unwinder output is scary; while it is useful for
> > + * debugging kernel issues, it can also allow an attacker to leak kernel
> > + * stack contents.
> > + * Doing this in a manner that is at least safe from races would require
> > + * some work to ensure that the remote task can not be scheduled; and
> > + * even then, this would still expose the unwinder as local attack
> > + * surface.
> > + * Therefore, this interface is restricted to root.
> > + */
> The /proc file is 0400 so the user can only read owned-by-self stacks,
> yes? In what way could exposure of one's own kernel stack contents
> lead to plausible attacks? I guess maybe post-setuid, perhaps?
> I do think we're owed considerably more explanation of the present risk
> before considering a somewhat dangerous -stable backport, please.
I sent a bug report to security@. The short version: Currently, you
can use /proc/self/task/*/stack to cause a stack walk on a task you
control while it is running on another CPU. That means that the stack
can change under the stack walker. The stack walker does have guards
against going completely off the rails and into random kernel memory,
but it can interpret random data from your kernel stack as instruction
pointers and stack pointers. This can cause exposure of kernel stack
contents to userspace.
prev parent reply other threads:[~2018-09-27 22:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-27 15:33 [PATCH resend] proc: restrict kernel stack dumps to root Jann Horn
2018-09-27 18:29 ` Kees Cook
2018-09-27 22:29 ` Andrew Morton
2018-09-27 22:39 ` Jann Horn [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).