On Tue, 6 Nov 2018 01:12:57 +0300 Leonid Krivoshein wrote:
> 
> 05.11.2018 22:46, Andrey Savchenko пишет:
> >> [...] Только боюсь, масштаб проблемы неизвестен, он
> >> может не ограничиваться systemd. И главное, требуется время на ловлю
> >> блох, хотя если быстрее и проще вкорячить haveged, то "не будет у нас
> >> ничего более постоянного, чем временное"!
> > Вкорячим. А потом через пару-тройку лет будет разгромный позор по
> > наличию в Альте и только Альте уязвимости из-за ненадёжного
> > источника энтропии для криптозадач.
> 
> Он же будет не единственным источником?

haveged пишет данные в /dev/random, поэтому с точностью до xor он
будет единственным источником при исчерпании собственного пула ядра.
Мало того, если сделать xor (или иные воспроизводимые манипуляции)
с M бит случайных данных и N бит неслучайных (M < N), мы не получим
N бит случайных данных. Энтропия системы всё равно будет уменьшена.

> И предлагается как временный воркэраунд только на раннем этапе загрузки.

Этого будет достаточно для подрыва безопасности. Если внутреннее
состояние (пул) libgcrypt будет инициализирован не случайным
числом, но все полученные на его основе данные, включая сессионное
ключи шифрования, будут нестойкими.

> 06.11.2018 00:32, Dmitry V. Levin пишет:
> > [...]
> > И выкиньте haveged куда подальше.

+1

> Если haveged добавляет энтропию, она так или иначе пропускается через 
> ядерный крипто-фильтр, энтропию выдаёт в конечном итоге ядро, которое 
> всё равно использует несколько разных источников.

Ядро не создаёт энтропию само, а лишь собирает её из разных
источников и перемешивает пул с целью недопущения накопления
неравномерностей в выборке.

Посмотри drivers/char/random.c, функцию _mix_pool_bytes():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n511

При использовании haveged получается, что пул случайных данных
размывается пулом не таких уж и случаных. Это убивает на корню всё
доверие к /dev/random.

> А вот отсутствие дополнительного источника энтропии в нужный
> момент, по крайней мере, до исправления CVE-2018-1108, можно
> считать проблемой.

Это CVE не о нашей проблеме, а о другом: /dev/random слишком рано
выдавал данные.

Best regards,
Andrew Savchenko