linux-kernel - Re: [PATCH resend] proc: restrict kernel stack dumps to root

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Sep 2018 15:29:08 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Jann Horn <jannh@...gle.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Ken Chen <kenchen@...gle.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Will Deacon <will.deacon@....com>,
        Laura Abbott <labbott@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Security Officers <security@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH resend] proc: restrict kernel stack dumps to root

On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn <jannh@...gle.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: stable@...r.kernel.org
> Signed-off-by: Jann Horn <jannh@...gle.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.