netdev - Re: Flaw in "random32: update the net random state on interrupt and activity"

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: <20200805220550.GA785826@mit.edu>
Date:   Wed, 5 Aug 2020 18:05:50 -0400
From:   tytso@....edu
To:     Marc Plumb <lkml.mplumb@...il.com>
Cc:     Willy Tarreau <w@....eu>, netdev@...r.kernel.org,
        aksecurity@...il.com, torvalds@...ux-foundation.org,
        edumazet@...gle.com, Jason@...c4.com, luto@...nel.org,
        keescook@...omium.org, tglx@...utronix.de, peterz@...radead.org,
        stable@...r.kernel.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and
 activity"

On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
> Isn't get_random_u32 the function you wrote to do that? If this needs to be
> cryptographically secure, that's an existing option that's safe.
> 
> The fundamental question is: Why is this attack on net_rand_state problem?
> It's Working as Designed. Why is it a major enough problem to risk harming
> cryptographically important functions?

I haven't looked at the users of net_rand_state, but historically, the
networking subsystem has a expressed a (perceived?) need for *very* fast
mostly-random-but-if-doens't-have-to-be-perfect-numbers-our-benchmarks-
are-way-more-important numbers.   As in, if there are extra cache line
misses, our benchmarks would suffer and that's not acceptable.

One of the problems here is that it's not sufficient for the average case
to be fast, but once in every N operations, we need to do something that
requires Real Crypto, and so that Nth time, there would be an extra lag
and that would be the end of the world (at least as far as networking
benchmarks are concerned, anyway).   So in other words, it's not enough for
the average time to run get_random_u32() to be fast, they care about the 95th or
99th percentile number of get_random_u32() to be fast as well.

An example of this would be for TCP sequence number generation; it's
not *really* something that needs to be secure, and if we rekey the
RNG every 5 minutes, so long as the best case attack takes at most,
say, an hour, if the worst the attacker can do is to be able to carry
out an man-in-the-middle attack without being physically in between
the source and the destination --- well, if you *really* cared about
security the TCP connection would be protected using TLS anyway.  See
RFC 1948 (later updated by RFC 6528) for an argument along these
lines.

> This whole thing is making the fundamental mistake of all amateur
> cryptographers of trying to create your own cryptographic primitive. You're
> trying to invent a secure stream cipher. Either don't try to make
> net_rand_state secure, or use a known secure primitive.

Well, technically it's not supposed to be a secure cryptographic
primitive.  net_rand_state is used in the call prandom_u32(), so the
only supposed guarantee is PSEUDO random.

That being said, a quick "get grep prandom_u32" shows that there are a
*huge* number of uses of prandom_u32() and whether they are all
appropriate uses of prandom_u32(), or kernel developers are using it
because "I haz a ne3D for spE3d" but in fact it's for a security
critical application is a pretty terrifying question.  If we start
seeing CVE's getting filed caused by inappropriate uses of
prandom_u32, to be honest, it won't surprise me.

						- Ted