Re: linux /dev/random initialization CVE-2018-1108
On Mon, Dec 17, 2018 at 10:05:55PM +0300, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 18:48> > Пришлось уже позаменять syslog-ng на rsyslog, потому что первый вызывает
> > getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие
> > претензии были). Хорошо что sshd так не делает, иначе на серверах
> > пришлось бы его под inetd переводить.
>
> Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему
> ему urandom не угодил?
Насколько я разбираюсь в медицине, он как раз urandom и читает.
Вот что написано в мане random(7):
* The Linux-specific getrandom(2) system call, available since Linux
3.17. This system call provides access either to the same source as
/dev/urandom (called the urandom source in this page) or to the same
source as /dev/random (called the random source in this page). The
default is the urandom source; the random source is selected by
specifying the GRND_RANDOM flag to the system call. (The geten‐
tropy(3) function provides a slightly more portable interface on top
of getrandom(2).)
А вот что делает syslog-ng, фрагмент трассы, который я отправил в BT:
------------------------------------------------------------------------
1501 22:44:00 getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29", 32, 0) = 32 <322.583360>
Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
------------------------------------------------------------------------
Флаги здесь, как видно, нулевые, в то время как GRND_NONBLOCK = 1,
GRND_RANDOM = 2. Так что именно urandom он и читает, и блокируется
на нём на 5 минут.
> > Зато появился новый квест: писать программы так, чтобы они рандомные
> > битики получали асинхронно, в отдельном треде. Рядом с резолвером.
>
> Опять-таки, если им нужна настоящая энтропия, то им ее все равно
> дожидаться.
Да, это правильно, но теперь нужно понимать, что этом сисколе можно крепко
зависнуть, а это может быть критично. Для syslog-ng квест выглядит так:
автор должен был догадаться, что сначала нужно создать сокет в /dev/log
и сказать ему listen(), иначе некоторые сервисы (например, sshd) не захотят
запускаться и процесс загрузки встанет. Так что просто сделать костыль,
принудительно отправив syslog-ng в бэкграуд -- не получится. Я пробовал,
на SysV-init. Возможно, с systemd результат будет иной, но проблема
имеется, для других утилит она может проявляться иначе.
--
Eugene Berdnikov
Reply to: