linux-kernel - Re: [PATCH] vfsprintf: only hash addresses in security environment

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:   Wed, 4 Mar 2020 10:34:35 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Jason Yan <yanaijie@...wei.com>
Cc:     pmladek@...e.com, rostedt@...dmis.org,
        sergey.senozhatsky@...il.com, andriy.shevchenko@...ux.intel.com,
        linux@...musvillemoes.dk, linux-kernel@...r.kernel.org,
        Scott Wood <oss@...error.net>,
        "Tobin C . Harding" <tobin@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Daniel Axtens <dja@...ens.net>
Subject: Re: [PATCH] vfsprintf: only hash addresses in security environment

On Wed, Mar 04, 2020 at 08:47:07PM +0800, Jason Yan wrote:
> When I am implementing KASLR for powerpc, Scott Wood argued that format
> specifier "%p" always hashes the addresses that people do not have a
> choice to shut it down: https://patchwork.kernel.org/cover/11367547/
> 
> It's true that if in a debug environment or security is not concerned,
> such as KASLR is absent or kptr_restrict = 0,  there is no way to shut
> the hashing down except changing the code and build the kernel again
> to use a different format specifier like "%px". And when we want to
> turn to security environment, the format specifier has to be changed
> back and rebuild the kernel.
> 
> As KASLR is available on most popular platforms and enabled by default,
> print the raw value of address while KASLR is absent and kptr_restrict
> is zero. Those who concerns about security must have KASLR enabled or
> kptr_restrict set properly.

Sorry, but no: %p censoring is there to stem the flood of endless pointer
leaks into logs, sysfs, proc, etc. These are used for attacks to build
reliable kernel memory targets, regardless of KASLR. (KASLR can be
bypassed with all kinds of sampling methods, side-channels, etc.)

Linus has rejected past suggestions to provide a flag for it[1],
wanting %p to stay unconditionally censored.

-Kees

[1] https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/

> 
> Cc: Scott Wood <oss@...error.net>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: "Tobin C . Harding" <tobin@...nel.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Daniel Axtens <dja@...ens.net>
> Signed-off-by: Jason Yan <yanaijie@...wei.com>
> ---
>  lib/vsprintf.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..f74131b152a1 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2253,8 +2253,15 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
>  		return err_ptr(buf, end, ptr, spec);
>  	}
>  
> -	/* default is to _not_ leak addresses, hash before printing */
> -	return ptr_to_id(buf, end, ptr, spec);
> +	/*
> +	 * In security environment, while kaslr is enabled or kptr_restrict is
> +	 * not zero, hash before printing so that addresses will not be
> +	 * leaked. And if not in a security environment, print the raw value
> +	 */
> +	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) || kptr_restrict)
> +		return ptr_to_id(buf, end, ptr, spec);
> +	else
> +		return pointer_string(buf, end, ptr, spec);
>  }
>  
>  /*
> -- 
> 2.17.2
> 

-- 
Kees Cook