linux-kernel - Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

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: <20181030183723.GI10011@roeckx.be>
Date:   Tue, 30 Oct 2018 19:37:23 +0100
From:   Kurt Roeckx <kurt@...ckx.be>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Sebastian Andrzej Siewior <sebastian@...akpoint.cc>,
        912087@...s.debian.org,
        "Package Development List for OpenSSL packages." 
        <pkg-openssl-devel@...oth-lists.debian.net>,
        linux-kernel@...r.kernel.org,
        Bernhard Übelacker <bernhardu@...lbox.org>,
        pkg-systemd-maintainers@...ts.alioth.debian.org,
        debian-ssh@...ts.debian.org, 912087-submitter@...s.debian.org
Subject: Re: Bug#912087: openssh-server: Slow startup after the upgrade to
 7.9p1

On Tue, Oct 30, 2018 at 10:15:44AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote:
> > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> > the entropy count after it was written. Those two are documented in
> > random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded.
> > It does also the job, too.
> > 
> > Ted, is there any best practise what to do with the seed which as
> > extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to
> > speed up init or just write to back to urandom and issue RNDRESEEDCRNG?
> 
> The reason why writing to /dev/[u]random via something like:
> 
>     cat /var/lib/random/seed > /dev/random
> 
> Dosn't bump the the entropy counter is because it's possible that an
> attacker could read /var/lib/random/seed.  Even if the seed file is
> refreshed on shutdown, (a) the attacker could have read the file while
> the system is down, or (b) the system could have crashed so the seed
> file was not refreshed and the attacker could have read the file
> before the crash.

So are you saying that the /var/lib/random/seed is untrusted, and
should never be used, and we should always wait for fresh entropy?

Anyway, I think if an attacker somehow has access to that file,
you have much more serious problems.


Kurt