netdev - Re: [PATCH] random: seed random_int_secret at least poorly at core

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131114041829.GA26901@order.stressinduktion.org>
Date:	Thu, 14 Nov 2013 05:18:30 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Daniel Borkmann <dborkman@...hat.com>, davem@...emloft.net,
	shemminger@...workplumber.org, fweimer@...hat.com,
	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
	linux-wireless@...r.kernel.org, keescook@...omium.org
Subject: Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time

On Wed, Nov 13, 2013 at 09:54:48PM -0500, Theodore Ts'o wrote:
> On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote:
> > > It is needed by fork to set up the stack canary. And this actually gets
> > > called before the secret is initialized.
> > 
> > Maybe we could use this for the time being and use the seeding method
> > of kaslr as soon as it hits the tree?
> 
> Hmm, from what I can tell even early_initcall() is going to be early
> enough.  The stack canary is set up by boot_init_stack_canary(), which
> is run very, very early in start_kerne() --- way before
> early_initcalls, or even before interrupts are enabled.  So adding
> random_int_secret_init_early() as a core_initcall is still too late.

Actually I tried to protect the tsk->stack_canary = get_random_int()
in fork.c. It sets up the per-task canary.

> I wonder if we need to do something in common with what Kees has been
> considering for the kaslr code, since it's a similar issue --- we need
> random number way earlier than we can really afford to initialize
> /dev/random.

Definiteley. I would also propose hashing the boot arguments, often
enough there is a filesystem UUID in there, or even hash the multiboot
information we are given from grub. Maybe compile-time entropy, at least
a bit.

> P.S.  Unless I'm missing something (and I hope I am), it would appear
> that the stack canary is going to easily predictable by an attacker on
> non-x86 platforms that don't have RDRAND.  Has someone tested whether
> or not the stack canary isn't constant across ARM or pre-Sandy Bridge
> x86 systems?

In case of protection for interrupt stacks and early cmwq threads,
it looks pretty bad from a first look at the source (at least for the
first initialized CPU).

I'll try to do some tests tomorrow.

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html