Re: linux /dev/random initialization CVE-2018-1108
Damir Hakimov -> Debian Russian Mailing List @ Tue, 18 Dec 2018 22:59:57 +0400: >> > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе >> > > требуется начать работать - обрабатывать какие-то сетевые запросы, >> > > шуршать диском и т.д. >> > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > нагреваемому резистору, пятна на солнце для этой самой энтропии? В рассматриваемых случаях обычно ни микрофона, ни АЦП нет, а пятна на солнце есть, но вот данных о них опять же нет. Все-таки беседа в основном о серверах, причем часто о виртуальных. Может быть, ядерный ДСЧ и умеет задействовать микрофон, если он вдруг найдется. Конструкцию из АЦП с резистором — вряд ли, потому как те полтора землекопа, которые ее соберут, нехай сами дописывают этот кусок кода и оценивают собранную энтропию.
Re: linux /dev/random initialization CVE-2018-1108
Vladimir Zhbanov -> debian-russian@lists.debian.org @ Tue, 18 Dec 2018 23:25:46 +0300: >> > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет >> > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к >> > нагреваемому резистору, пятна на солнце для этой самой энтропии? >> >> Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро >> проскочить место, где системный демон завис на getrandom(). >> Так что по крайней мере драйвер клавиатуры задействован. >> >> Но у серверов кроме сети существенных источников шума обычно нет. > Отслеживаемые напряжения питания материнской платы и процессора, > которых обычно несколько, по-любому плавают. Плавает и > температура, но гораздо медленнее, что, впрочем, тоже можно > использовать. Про какие-то процессоры читал, что там специально > улучшали качество и скорость отслеживания напряжений, по ходу даже > датчики и АЦП в том же корпусе были, чтобы энтропию собирать. Плохо там со случайностью без специальных мер. Для мониторинга высокоточное измерение не нужно, а при невысокой точности энтропии там кот наплакал. А если речь про виртуалку, так и вообще никак. Кто ж ей даст реальные данные о напряжении на плате?
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 10:35:51PM +0300, Eugene Berdnikov wrote: ... > > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > > нагреваемому резистору, пятна на солнце для этой самой энтропии? > > Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро > проскочить место, где системный демон завис на getrandom(). > Так что по крайней мере драйвер клавиатуры задействован. > > Но у серверов кроме сети существенных источников шума обычно нет. Отслеживаемые напряжения питания материнской платы и процессора, которых обычно несколько, по-любому плавают. Плавает и температура, но гораздо медленнее, что, впрочем, тоже можно использовать. Про какие-то процессоры читал, что там специально улучшали качество и скорость отслеживания напряжений, по ходу даже датчики и АЦП в том же корпусе были, чтобы энтропию собирать. -- Vladimir
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 10:59:57PM +0400, Damir Hakimov wrote: > > Artem Chuprina wrote: > > > > > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > > > шуршать диском и т.д. > > > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к > нагреваемому резистору, пятна на солнце для этой самой энтропии? Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро проскочить место, где системный демон завис на getrandom(). Так что по крайней мере драйвер клавиатуры задействован. Но у серверов кроме сети существенных источников шума обычно нет. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
> Artem Chuprina wrote: > > > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > > шуршать диском и т.д. > Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет клином сошелся? Почему не задействовать микрофон, АЦП подключенный к нагреваемому резистору, пятна на солнце для этой самой энтропии? -- DamirX
Re: Внешний нжмд и хранитель экрана
Проблема частично решена, дальше её разрешать вряд ли буду. Решение - отключение хранителя экрана. Спасибо за внимание.0:44, 17 декабря 2018 г., "Александр Завгородний" :Доброго времени суток!Дано:Дебиан 9.5 амд64, среда Мате и внешний нжмд с интерфейсом усб.Вопрос:При копировании на нжмд (делаю резервную копию файлов), если окно свернуть и заблокировать экран, копирование приостанавливается, нжмд засыпает, а времени и так немного, если экран не блокировать, то всё идёт как надо, на других машинах с предыдущими версиями Дебиана всё с этим в порядке. Прошу помощи в этом вопросе, то есть, чтобы при блокировке экрана копирование файлов не при останавливалось. -- Отправлено из мобильного приложения Яндекс.Почты-- Отправлено из мобильного приложения Яндекс.Почты
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV. То-то я смотрю у меня в системе этот файлик 2015 годом датирован.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:28:01 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > > On Tue, 18 Dec 2018 14:16:49 +0300 > > Eugene Berdnikov wrote: > > > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > > > А вот кто бы объяснил: в initscripts есть > > > скрипт /etc/init.d/urandom, судя по датам модификации > > > файла /var/lib/urandom/random-seed скриптик исправно отрабатывает > > > при шатдауне и должен отрабатывать при загрузке, какого же хрена > > > ядро (во всяком случае, 4.17) блокируется на urandom, вместо > > > того, чтобы сохранённый пул использовать? Кто-нибудь в курсе > > > последних веяний в этой области? > > > > Так в системе systemd или sysV init? > > SysV.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 02:24:11PM +0300, Victor Wagner wrote: > On Tue, 18 Dec 2018 14:16:49 +0300 > Eugene Berdnikov wrote: > > > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > > > А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, > > судя по датам модификации файла /var/lib/urandom/random-seed скриптик > > исправно отрабатывает при шатдауне и должен отрабатывать при > > загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется > > на urandom, вместо того, чтобы сохранённый пул использовать? > > Кто-нибудь в курсе последних веяний в этой области? > > Так в системе systemd или sysV init? SysV. -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 14:16:49 +0300 Eugene Berdnikov wrote: > On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, > судя по датам модификации файла /var/lib/urandom/random-seed скриптик > исправно отрабатывает при шатдауне и должен отрабатывать при > загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется > на urandom, вместо того, чтобы сохранённый пул использовать? > Кто-нибудь в курсе последних веяний в этой области? Так в системе systemd или sysV init?
Re: linux /dev/random initialization CVE-2018-1108
On Tue, Dec 18, 2018 at 01:37:47PM +0300, Victor Wagner wrote: > On Tue, 18 Dec 2018 13:30:06 +0300 > Artem Chuprina wrote: > > Отчасти да. Но энтропию оно набирает, сколь я помню, не только с > > сетевых запросов к себе, но и вообще со всего, что пролетает мимо > > сетевки. > > Ага щаз, так уж в эпоху управляемых свитчей и полетит что-нибудь > мимо сетевки, что этому хосту не адресовано. ARP-запросы разве что. Но > много ли их в типичной серверной стойке? Все бродкасты и мультикасты передаются ядру, и для типичной стойки такого мусора достаточно. Мало его там, где сеть хорошо структурирована, выделены серверные vlan'ы и лишних машин в этих сегментах нет. А вот кто бы объяснил: в initscripts есть скрипт /etc/init.d/urandom, судя по датам модификации файла /var/lib/urandom/random-seed скриптик исправно отрабатывает при шатдауне и должен отрабатывать при загрузке, какого же хрена ядро (во всяком случае, 4.17) блокируется на urandom, вместо того, чтобы сохранённый пул использовать? Кто-нибудь в курсе последних веяний в этой области? -- Eugene Berdnikov
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 13:30:06 +0300 Artem Chuprina wrote: > > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > > требуется начать работать - обрабатывать какие-то сетевые запросы, > > шуршать диском и т.д. > > > Но она не может стартовать ни одного сетевого сервиса, не набрав > > достаточно энтропии хотя бы для urandom, потому что все сервисы > > нынче хотят какие-нибудь эфемерные ключи. А следовательно - и > > проявить хоть какую-то сетевую активность, равно и локальный > > ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки > > будет все равно иметь проблемы со своей случайностью. > > Отчасти да. Но энтропию оно набирает, сколь я помню, не только с > сетевых запросов к себе, но и вообще со всего, что пролетает мимо > сетевки. Ага щаз, так уж в эпоху управляемых свитчей и полетит что-нибудь мимо сетевки, что этому хосту не адресовано. ARP-запросы разве что. Но много ли их в типичной серверной стойке? (а уж если это у нас виртуальный эзернет какой-нибудь системы управления виртуальными машинами...) > А сетевую активность без проблем со случайностью можно сделать, > например, так: взять совсем уже псевдослучайное число, например, > 8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый > PRNG, который не криптографического качества, а дальше в параллель > попинговать его следующие значения, периодически подмешивая тайминги > ответов. С этого ядро наберет уже вполне вменяемую энтропию. Интересная идея. Может такую утилитку написать и запускать из post-up в /etc/network/interfaces? Только стартовый адрес надо конфигурируемым сделать. А то вдруг из этого датацентра нет роутинга до 8.8.8.8. --
Re: linux /dev/random initialization CVE-2018-1108
Victor Wagner -> Artem Chuprina @ Tue, 18 Dec 2018 12:52:11 +0300: >> Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала >> набрать энтропию, и только потом уже раскручивать псевдорандомизацию. >> А прикапывать ее между перезагрузками чревато тем же боком. Так-то >> считается, что urandom — псевдослучайный, но с криптографическим >> качеством. А значит, должен иметь в виду криптографическую модель >> угроз. > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе > требуется начать работать - обрабатывать какие-то сетевые запросы, > шуршать диском и т.д. > Но она не может стартовать ни одного сетевого сервиса, не набрав > достаточно энтропии хотя бы для urandom, потому что все сервисы нынче > хотят какие-нибудь эфемерные ключи. А следовательно - и проявить хоть > какую-то сетевую активность, равно и локальный ввод-вывод. Поскольку > клиентов нет, а любая имитация нагрузки будет все равно иметь проблемы > со своей случайностью. Отчасти да. Но энтропию оно набирает, сколь я помню, не только с сетевых запросов к себе, но и вообще со всего, что пролетает мимо сетевки. А сетевую активность без проблем со случайностью можно сделать, например, так: взять совсем уже псевдослучайное число, например, 8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый PRNG, который не криптографического качества, а дальше в параллель попинговать его следующие значения, периодически подмешивая тайминги ответов. С этого ядро наберет уже вполне вменяемую энтропию.
Re: linux /dev/random initialization CVE-2018-1108
On Tue, 18 Dec 2018 12:24:57 +0300 Artem Chuprina wrote: > Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала > набрать энтропию, и только потом уже раскручивать псевдорандомизацию. > А прикапывать ее между перезагрузками чревато тем же боком. Так-то > считается, что urandom — псевдослучайный, но с криптографическим > качеством. А значит, должен иметь в виду криптографическую модель > угроз. Получается проблема курицы и яйца. Чтобы набрать энтропию, системе требуется начать работать - обрабатывать какие-то сетевые запросы, шуршать диском и т.д. Но она не может стартовать ни одного сетевого сервиса, не набрав достаточно энтропии хотя бы для urandom, потому что все сервисы нынче хотят какие-нибудь эфемерные ключи. А следовательно - и проявить хоть какую-то сетевую активность, равно и локальный ввод-вывод. Поскольку клиентов нет, а любая имитация нагрузки будет все равно иметь проблемы со своей случайностью. --
Re: linux /dev/random initialization CVE-2018-1108
Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018 23:22:51 +0300: > 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 минут. Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала набрать энтропию, и только потом уже раскручивать псевдорандомизацию. А прикапывать ее между перезагрузками чревато тем же боком. Так-то считается, что urandom — псевдослучайный, но с криптографическим качеством. А значит, должен иметь в виду криптографическую модель угроз. >> > Зато появился новый квест: писать программы так, чтобы они рандомные >> > битики получали асинхронно, в отдельном треде. Рядом с резолвером. >> >> Опять-таки, если им нужна настоящая энтропия, то им ее все равно >> дожидаться. > Да, это правильно, но теперь нужно понимать, что этом сисколе можно крепко > зависнуть, а это может быть критично. Для syslog-ng квест выглядит так: > автор должен был догадаться, что сначала нужно создать сокет в /dev/log > и сказать ему listen(), иначе некоторые сервисы (например, sshd) не захотят > запускаться и процесс загрузки встанет. Так что просто сделать костыль, > принудительно отправив syslog-ng в бэкграуд -- не получится. Я пробовал, > на SysV-init. Возможно, с systemd результат будет иной, но проблема > имеется, для других утилит она может проявляться иначе. Да, одна проблема раскрыла наличие другой. Ну что ж, бывает...