https://www.opennet.me/openforum/vsluhforumID3/114210.html Раскрыты (https://bugs.chromium.org/p/project-zero/issues/detail?id=1559) сведения об уязвимости (CVE-2018-1108 (https://security-tracker.debian.org/tracker/CVE-2018-1108)) в реализации генератора случайных чисел, предлагаемого в ядре Linux. Уязвимость охватывает несколько проблем, выявленных в процессе аудита, проведённого инженерами компании Google. Найденные проблемы снижают уровень энтропии при инициализации и приводят к ужудшению качества генерации случайных чисел через /dev/urandom в процессе загрузки системы и спустя короткое время после загрузки (от нескольких секунд до минуты). Уязвимость проявляется только для ключей, создаваемых на раннем этапе загрузки (до стадии инициализации RNG crng_init=2), так как на данной стадии параметры случайных чисел не отвечают требованиям, предъявляемым для криптографических операций. <br><br><br><br>Из проблем отмечается игнорирование некоторых источников энтропии на ранней стадии загрузки, ненадлежащее взаимодействие между ядром и пространством пользователя с построенной эн https://www.opennet.me/openforum/vsluhforumID3/114210.html#112 Tue, 22 May 2018 13:13:27 GMT &gt;&gt; Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы <br>&gt;&gt; и не позиционируется как криптостойкий источник. О чём вообще писк-то?<br>&gt; Я, конечно, иронизировал над сабжом и ключами-криптографией, но...<br>&gt; //BTW, коллеги, как вовнутрь QEMU "пробрасывать" немного рандома из родительской системы? <br><br>Не-rtfm с мойе стороны. Sorry за шум.<br><br><br>https://wiki.qemu.org/Features/VirtIORNG<br><br>$ man qemu-system-i386 2&gt;/dev/null &#124;grep rng<br> -object rng-random,id=id,filename=/dev/random<br> reference this entropy backend from the virtio-rng device. The filename<br> -object rng-egd,id=id,chardev=chardevid<br> will be used to reference this entropy backend from the virtio-rng<br>$ _<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#111 Tue, 22 May 2018 12:41:18 GMT &gt; Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы <br>&gt; и не позиционируется как криптостойкий источник. О чём вообще писк-то?<br><br>Я, конечно, иронизировал над сабжом и ключами-криптографией, но...<br><br>...изменение апи, как то блокировка чтения /urandom (как коллеги и указывали выше, да) , удариро по вот моему ныне любимому GNU GuixSD: https://debbugs.gnu.org/31268 .<br><br>Они там занимаются "авангардом" в виде системных тестов (тесты разлиных конф.системы - после установки в VM) -- и вот как раз на _установке_ в VM оно замерзает [вроде, как] намертво на "простой" генерации UUID-а при создании раздела parted-ом. В виртуалке во время загрузки, видимо, с источниками рандома туго. Совсем то есть.<br><br>//BTW, коллеги, как вовнутрь QEMU "пробрасывать" немного рандома из родительской системы?<br><br>--<br>https://lists.gnu.org/archive/html/help-guix/2018-05/msg00137.html<br>https://lists.gnu.org/archive/html/help-guix/2018-04/msg00217.html<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#110 Sat, 05 May 2018 05:53:32 GMT &gt; Давай по честному. Ты когда-нибудь видел такое на практике? И я нет. <br><br>Ну я видел. С неких пор ядро при этом натурально вопит про "uninitialized read" из urandom'а, если энтропии мало.<br><br>И если на десктопе среднего пошиба это еще не особо большая проблема и там на такое нарваться не так просто, то вот например на виртуалках, или иногда еще встраиваемых системах с энтропией на старте может быть довольно тухло, по причине небольшого числа источников оной и весьма детерминированного состояния системы на старте и повторяемости процессов при каждой загрузке. А "случайные" числа которые повторяются при каждой загрузке или серии оных выбираются из весьма конечного ассортимента наборов - никому не надо, потому что ведет к попаданию в стиле Debian. Когда атакующие начнут ключи просто угадывать.<br><br>На этом феномене основан например метод скоростного выноса WPS на роутерах - в системе мало энтропии, поэтому какой "случайный" PIN задумал роутер атакующие могут угадать не за (в среднем) половину от 9999 попыток, что в https://www.opennet.me/openforum/vsluhforumID3/114210.html#109 Sat, 05 May 2018 05:47:02 GMT &gt; И зачем тягать подписанные общедоступные пакеты, лежащие на куче зеркал, через Tor? <br><br>А чтобы не информировать атакующего лишний раз.<br>1) Какой софт у тебя вообще в системе установлен. Это может использоваться для слежки или весьма прицельных атак.<br>2) Атаковать зная точную версию программы в системе значительно удобнее и проще чем наобум. <br>3) Пальба факта незаапдейченности системы так и просит сплойта в бубен.<br><br>А вот каким милым, добрым и хорошим способом транзитные узлы могут использовать знание списка пакетов и их версий - я даже как-то так сходу и придумать не могу. В свете таких соотношений так и просится зарубить этот источник информации. Ни к чему атакующим и прочим шпикам это все знать. Это знание не несет ничего хорошего легитимным владельцам систем.<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#108 Sat, 05 May 2018 05:39:17 GMT &gt; да, похоже, повиснут только шибкоумные, которые вместо файловых операций используют getrandom(2) <br><br>Нет, блин, лучше пусть нагенерят дырявых ключей, как дебиан в свое время, так что вся планета потом резко рекеится. Потому что весь список возможных ключей занимает едва ли десяток мегабайт, так что любой желающий может пойти да и угадать ваш ключ, за весьма обозримое число попыток. Ну и нафиг такие ключи нужны, спрашивается? <br><br>А так то да, если замок сделан их пластилина - это по своему удобно, можно не лезть в карман за ключами и просто снять его голыми руками. Но говорят что с этим есть некоторые нюансы.<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#107 Fri, 04 May 2018 14:35:37 GMT &gt; Лучше скинутся на свободную нардварную реализацию ГСЧ, что бы в USB воткнул, <br><br>Воткни в usb wifi свисток на ath9k и разреши собирать энтропию с его ADC в конфиге ядра. Получишь вагон энтропии. При том в случае ADC бэкдор всучить особо некуда, да и ядро не напрямую это трескает все-же. А прошивка там опенсорсная как раз. Древняя проприетарная небось и не умеет отсчеты ADC наружу из свистка вытаскивать.<br><br>В "свободной реализации" воткнутой в usb - один хрен будет скорее всего ADC. А где там еще энтропию особо брать? С "крутого и правильного" хардварного генератора случайных чисел? Лол!<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#106 Fri, 04 May 2018 14:14:36 GMT &gt; подожди пару часиков, ничего не нажимая и мыша не шевеля - если <br>&gt; оно все же стартанет - да, оно.<br>&gt; Багрепорт - майнтейнеру дистрибутива, Линуса оно не интересует, у него палец.<br><br>У майнтайнеров чего доброго тоже палец может оказаться - системда нынче видите ли умеет random seed между перезагрузками сохранять и скармливать ядру, во избежание подобных приколов. А если кто хотел быть самым умным - так пусть и простреленную пятку сам лечит.<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#104 Fri, 04 May 2018 13:34:36 GMT Проблема в том что urandom по задумке своей - не блокирующий. Программы как-то не ожидают того что они на этом могут встрять и встревать там где это не ожидается - вовсе даже и не почтительно. И получается дилемма: надо или встрять программу с неизвестным результатом, потому что это нарушает допущения сделанные при программировании, или программа получит хреновую энтропию. На самом деле - безвыигрышный вариант и требуется некий пересмотр подода, чтобы переиграть соотношения.<br> https://www.opennet.me/openforum/vsluhforumID3/114210.html#103 Thu, 03 May 2018 15:19:14 GMT &gt; Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы <br>&gt; и не позиционируется как криптостойкий источник. О чём вообще писк-то?<br><br>Секьюрити сёркус снова в городке Линуса нашего Тормальдса. С новыми поэтессами из Гран Гугле Опера.<br>