netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Plumb <lkml.mplumb@gmail.com>
To: tytso@mit.edu, w@1wt.eu
Cc: netdev@vger.kernel.org, aksecurity@gmail.com,
	torvalds@linux-foundation.org, edumazet@google.com,
	Jason@zx2c4.com, luto@kernel.org, keescook@chromium.org,
	tglx@linutronix.de, peterz@infradead.org, stable@vger.kernel.org
Subject: Flaw in "random32: update the net random state on interrupt and activity"
Date: Tue, 4 Aug 2020 17:57:00 -0700	[thread overview]
Message-ID: <aef70b42-763f-0697-f12e-1b8b1be13b07@gmail.com> (raw)
In-Reply-To: <9f74230f-ba4d-2e19-5751-79dc2ab59877@gmail.com>

Willy and Ted,

This commit has serious security flaws 
f227e3ec3b5cad859ad15666874405e8c1bbc1d4


TL;DR This change takes the seed data from get_random_bytes and 
broadcasts it to the network, thereby destroying the security of 
dev/random. This change needs to be reverted and redesigned.


It is inefficient:

This function is called from an interrupt context, so there is no chance 
of a CPU switch, therefore the this_cpu_add function should be 
__this_cpu_add. This is a sign that the patch may have been rushed and 
may not be suitable for a stable release.


It is fixing the wrong problem:

The net_rand_state PRNG is a weak PRNG for the purpose of avoiding 
collisions, not to be unguessable to an attacker. The network PRNG does 
not need secure seeding. If you need a secure PRNG then you shouldn't be 
using the net_rand_state PRNG. Please reconsider why you think that this 
change is necessary.

It dramatically weakens dev/random:

Seeding two PRNGs with the same entropy causes two problems. The minor 
one is that you're double counting entropy. The major one is that anyone 
who can determine the state of one PRNG can determine the state of the 
other.

The net_rand_state PRNG is effectively a 113 bit LFSR, so anyone who can 
see any 113 bits of output can determine the complete internal state.

The output of the net_rand_state PRNG is used to determine how data is 
sent to the network, so the output is effectively broadcast to anyone 
watching network traffic. Therefore anyone watching the network traffic 
can determine the seed data being fed to the net_rand_state PRNG. Since 
this is the same seed data being fed to get_random_bytes, it allows an 
attacker to determine the state and there output of /dev/random. I 
sincerely hope that this was not the intended goal. :)

Thank you
Marc

       reply	other threads:[~2020-08-05  0:57 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9f74230f-ba4d-2e19-5751-79dc2ab59877@gmail.com>
2020-08-05  0:57 ` Marc Plumb [this message]
2020-08-05  1:02 ` Flaw in "random32: update the net random state on interrupt and activity" Linus Torvalds
2020-08-05  2:49 ` Willy Tarreau
2020-08-05 15:34   ` tytso
2020-08-05 16:06     ` Marc Plumb
2020-08-05 19:38       ` Willy Tarreau
2020-08-05 22:21         ` Marc Plumb
2020-08-06  6:30           ` Willy Tarreau
2020-08-06 17:18             ` Marc Plumb
2020-08-07  7:03               ` Willy Tarreau
2020-08-07 16:52                 ` Marc Plumb
2020-08-07 17:43                   ` Willy Tarreau
     [not found]                     ` <C74EC3BC-F892-416F-A95C-4ACFC96EEECE@amacapital.net>
2020-08-07 18:04                       ` Willy Tarreau
2020-08-07 18:10                       ` Linus Torvalds
2020-08-07 19:08                         ` Andy Lutomirski
2020-08-07 19:21                           ` Linus Torvalds
2020-08-07 19:33                             ` Andy Lutomirski
2020-08-07 19:56                               ` Linus Torvalds
2020-08-07 20:16                                 ` Andy Lutomirski
2020-08-07 20:24                                   ` Linus Torvalds
2020-08-07 19:59                     ` Marc Plumb
2020-08-07 22:19                       ` Willy Tarreau
2020-08-07 22:45                         ` Marc Plumb
2020-08-07 23:11                           ` Willy Tarreau
2020-08-05 22:05       ` tytso
2020-08-05 23:03         ` Andy Lutomirski
2020-08-06 17:00         ` Marc Plumb
2020-08-05 16:24     ` Jason A. Donenfeld
2020-08-05 16:53     ` Willy Tarreau
2020-08-05 15:44   ` Marc Plumb
2020-08-05 16:39     ` Linus Torvalds
2020-08-05 23:49       ` Stephen Hemminger
2020-08-08 15:26 George Spelvin
2020-08-08 17:07 ` Andy Lutomirski
2020-08-08 18:08   ` Willy Tarreau
2020-08-08 18:13   ` Linus Torvalds
2020-08-08 19:03   ` George Spelvin
2020-08-08 19:49     ` Andy Lutomirski
2020-08-08 21:29       ` George Spelvin
2020-08-08 17:44 ` Willy Tarreau
2020-08-08 18:19   ` Linus Torvalds
2020-08-08 18:53     ` Willy Tarreau
2020-08-08 20:47     ` George Spelvin
2020-08-08 20:52       ` Linus Torvalds
2020-08-08 22:27         ` George Spelvin
2020-08-09  2:07           ` Linus Torvalds
2020-08-11 16:01             ` Eric Dumazet
2020-08-08 19:18   ` Florian Westphal
2020-08-08 20:59     ` George Spelvin
2020-08-08 21:18     ` Willy Tarreau
2020-08-08 20:08   ` George Spelvin
2020-08-08 20:47     ` Linus Torvalds
2020-08-12  6:03 Sedat Dilek
2020-08-12  6:35 ` Sedat Dilek
2020-08-12  7:13   ` Sedat Dilek
2020-08-12 15:16 ` Eric Dumazet
2020-08-12 16:20   ` Sedat Dilek
2020-08-12 16:24     ` Eric Dumazet
2020-08-12 16:38       ` Sedat Dilek
2020-08-19  9:51         ` Sedat Dilek
2021-01-08 13:08       ` Sedat Dilek
2021-01-08 13:51         ` Sedat Dilek
2021-01-08 15:41           ` Eric Dumazet
2021-01-08 21:32             ` Sedat Dilek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aef70b42-763f-0697-f12e-1b8b1be13b07@gmail.com \
    --to=lkml.mplumb@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=aksecurity@gmail.com \
    --cc=edumazet@google.com \
    --cc=keescook@chromium.org \
    --cc=luto@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).