netdev - Re: [PATCH 01/12] netfilter: avoid get_random

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]

Message-ID: <20140106130451.GF28854@breakpoint.cc>
Date:	Mon, 6 Jan 2014 14:04:51 +0100
From:	Florian Westphal <fw@...len.de>
To:	Florian Westphal <fw@...len.de>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH 01/12] netfilter: avoid get_random_bytes calls

Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> On Mon, Jan 06, 2014 at 12:54:36PM +0100, Florian Westphal wrote:
> > Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> > Can you elaborate?  If entropy estimate is really really low
> > (because we're booting up), why would get_random_bytes() be a better
> > choice [ i understand net_get_random_once() is for delaying
> > the actual random_bytes call until a later point in time where we've
> > hopefully collected more entropy ]

[..]

> On some of my small virtual machines (amd64) I even see this message while
> login on the console (small iptables set also loaded before). In the mean
> time prandom_u32() is still seeded with maybe 3 bits (I once measured it)
> at the beginning and won't get a refresh until the nonblocking pool is
> fully initialized.

I see.  In this case it indeed could be a problem; I was doing this
change with the assumption that prandom is useable at ->checkenty time.

> > I specifically did not use net_get_random_once once because checkentry is
> > not a hotpath.
> > 
> > I don't see why get_random_bytes use increases the security margin, especially
> > considering none of these hashes have periodic run-time rehashing?
> > 
> > But sure, if you think this change is a problem, Pablo can just revert it.
> 
> I don't know if it is a real problem. Most of the time the initial seed
> should be enough, but I guess get_random_bytes would still be a more
> defensive choice. I would have used it. ;)

Alright.  Given that this went into -next, I think we have a few weeks to
investigate.

I will check if the specific hash uses are problematic in their own right
(due to lack of reseed) or if they are weakened by this change only.

I'll follow up on this.

Pablo/David, if you think this needs to be fixed RIGHT NOW then please
just issue a revert for a42b99a6e329654d376b330de057eff87686d890.

Thanks!
--
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