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

[Andrew Morton]

On Thu, 27 Sep 2018 17:33:16 +0200 Jann Horn <jannh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> Signed-off-by: Jann Horn <jannh@xxxxxxxxxx>

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.