linux-kernel - Re: [PATCH] avoid entropy starvation due to stack protection

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:	Fri, 14 Dec 2012 18:36:41 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Ted Ts'o <tytso@....edu>, lkml <linux-kernel@...r.kernel.org>,
	Jeff Liu <jeff.liu@...cle.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] avoid entropy starvation due to stack protection

On 13.12.2012 08:44:36, +0100, Stephan Mueller <smueller@...onox.de> wrote:

Hi Andrew,
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
>
> Hi Andrew,
>> On Tue, 11 Dec 2012 13:33:04 +0100
>> Stephan Mueller <smueller@...onox.de> wrote:
>>
>>> Some time ago, I noticed the fact that for every newly
>>> executed process, the function create_elf_tables requests 16 bytes of
>>> randomness from get_random_bytes. This is easily visible when calling
>>>
>>> while [ 1 ]
>>> do
>>> 	cat /proc/sys/kernel/random/entropy_avail
>>> 	sleep 1
>>> done
>> Please see
>> http://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch
>>
>> That patch is about one week from a mainline merge, btw.
> Initially I was also thinking about get_random_int. But stack protection
> depends on non-predictable numbers to ensure it cannot be defeated. As
> get_random_int depends on MD5 which is assumed to be broken now, I
> discarded the idea of using get_random_int.
>
> Moreover, please consider that get_cycles is an architecture-specific
> function that on some architectures only returns 0 (For all
> architectures where this is implemented, you have no guarantee that it
> increments as a high-resolution timer). So, the quality of
> get_random_int is questionable IMHO for the use as a stack protector.
>
> Also note, that other in-kernel users of get_random_bytes may be
> converted to using the proposed kernel pool to avoid more entropy drainage.
>
> Please note that the suggested approach of fully seeding a deterministic
> RNG never followed by a re-seeding is used elsewhere (e.g. the OpenSSL
> RNG). Therefore, I think the suggested approach is viable.

I would like to add one more thing to consider. As the get_random_int
state depends on a relatively predictable timer reading, especially on
architectures without get_cycles(), hashed by MD5, it gains strength
(read unpredictability, entropy) over time. I.e. the more random numbers
are *randomly* extracted, the more random the value is.

Since many applications that are intended to benefit from stack
protection are started during boot time (e.g. the SSH daemon, Web
servers, Mail servers, other networking servers), I would conclude that
at the time these applications need random values, the strength behind
get_random_int is very low.

With my proposed patch, we have a similar strength than /dev/urandom but
without the drag on entropy during normal operation time -- i.e. the
time when cryptography comes into play triggered by normal users. Only
at that time the system needs to conserve entropy.
>
> Ciao
> Stephan
>

-- 
| Cui bono? |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/