| Re: [chrony-users] Chrony vs. Linux RNG |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 23 Apr 2018, Miroslav Lichvar wrote:
On Sun, Apr 22, 2018 at 07:15:12PM +0200, Holger Hoffstätte wrote:
I test stable/LTS kernels to help Greg KH and just updated to 4.16.4-rc1.
This contains a few patches that are supposed to help with CVEs around
randomness, and which cause an interesting catch-22 that affects chrony,
hence this mail.
Thanks for the heads up.
I tried booting a VM with 4.17-rc2, which should include the patches
you are referring to, but didn't see any delays problems.
On what distro do you test it? Does it save and restore the random
seed on boot (e.g. the systemd-random-seed)?
The patches in question are in the stable queue and can be found under the
"random-*" prefix at:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.16
Long story short, is there something chrony can do to avoid this?
I guess it could use a non-blocking read for the urandom device (or
getrandom() syscall) and fall back to random(), but I'm not sure if it
would be a good idea from the security point of view.
Do not use /dev/random It gives no extra security over /dev/urandom, and can
block. Using it is a terrible idea no matter what you use it for.
The random() glibc routine is terribly weak.(It has nothing to do with
/dev/random and uses a totally different generator, and is easily (now adays)
breakable.) Just read /dev/urandom. (or getrandom with the GRND_NOBLOCK flag
set)
Why does it need to access any random number generators in the first
place?
There are few places in the chrony code that use random numbers. I
think the most important one is randomness added to transmit timestamp
in client requests in order to make it more difficult for attackers
(that don't see the request) to send you a valid response and mess
with your clock.
The code does seem to use /dev/urandom in general, except occasionally it uses
getrandom with 0 flag. (which is the same as urandom but blocking on initial
use if not enough randomness estimate is in the pool.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.