Раскрыты (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), так как на данной стадии параметры случайных чисел не отвечают требованиям, предъявляемым для криптографических операций.Из проблем отмечается игнорирование некоторых источников энтропии на ранней стадии загрузки, ненадлежащее взаимодействие между ядром и пространством пользователя с построенной энтропией, отсутствие передачи энтропии в NUMA CRNG на стадии инициализации. Для демонстрации проблемы на системе Intel Grass Canyon продемонстрировано создание условий, при которых уровень энтропии на стадии загрузки составил 105 бит вместо ожидаемых 4096 бит. Информация о проблеме раскрыта после
публикации (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) патчей к ядру Linux, устраняющих выявленные недостатки. Внесённые исправления приостанавливают выдачу значений /dev/urandom до накопления должной энтропии, что может привести к зависанию процесса загрузки из-за блокировки приложений, обращающихся к /dev/urandom на ранней стадии загрузки.URL: https://news.ycombinator.com/item?id=16972827
Новость: https://www.opennet.ru/opennews/art.shtml?num=48531
>что может привести к зависанию процесса загрузки из-за блокировки приложений, обращающихся к /dev/urandom на ранней стадии загрузки.Линус же себя тапком в грудь бил, что приложения не должны страдать ни в коем случае! Как же так?
Они и не страдают. Они ждут. Это на востоке называется "почтительное ожидание". И никаких страданий! :-)
Проблема в том что urandom по задумке своей - не блокирующий. Программы как-то не ожидают того что они на этом могут встрять и встревать там где это не ожидается - вовсе даже и не почтительно. И получается дилемма: надо или встрять программу с неизвестным результатом, потому что это нарушает допущения сделанные при программировании, или программа получит хреновую энтропию. На самом деле - безвыигрышный вариант и требуется некий пересмотр подода, чтобы переиграть соотношения.
#>>чисел через /dev/urandom в процессе загрузки системы
#>>проявляется только для ключей, создаваемых на раннем этапе загрузки
>>что может привести к зависанию процесса загрузки из-за блокировки приложений, обращающихся к /dev/urandom на ранней стадии загрузки.
> Линус же себя тапком в грудь бил, что приложения не должны страдать
> ни в коем случае! Как же так?Пользователи _u_random для генерации "ключей" должны страдать.
особенно на этапе загрузки.
теперь страдать будут все, так как ранее "бесконечный" urandom ведет себя в точности как обычный random - блокирует чтение и ждет. А, ну да - на загрузке, скорость которой мы оптимизировали-оптимизировали, да так и не выоптимизировали.Клоуны-псы, б-ский цирк :-(
Судя вот по этому: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ожидание добровольное, а так только ворнингов насыпет
это ж ядро - в ядре оно, вероятно, добровольное. А приложения использующие стандартный open/read - просто повиснут до wait_for_random_bytes - которую они вовсе не заказывали.
Судя по https://github.com/torvalds/linux/blob/master/drivers/char/r... таки urandom_read только ругается, но не блокируется. А wait добавлен для ядерных случайных чисел - инциализации SCSI и подобного
да, похоже, повиснут только шибкоумные, которые вместо файловых операций используют getrandom(2)
(это не "ядерные", это доступный через libc syscall, кажется, освященный позиксом)
Дайте угадаю, кто это... а, ну да, конечно же - все что завязано на openssl ;-) Нет, non-blocking вариант там есть, но те кто его использовали, могли и urandom не пользоваться, зачем самому себе снижать эффективность, если ты все равно умеешь ждать пока генератор разродится.
> да, похоже, повиснут только шибкоумные, которые вместо файловых операций используют getrandom(2)Нет, блин, лучше пусть нагенерят дырявых ключей, как дебиан в свое время, так что вся планета потом резко рекеится. Потому что весь список возможных ключей занимает едва ли десяток мегабайт, так что любой желающий может пойти да и угадать ваш ключ, за весьма обозримое число попыток. Ну и нафиг такие ключи нужны, спрашивается?
А так то да, если замок сделан их пластилина - это по своему удобно, можно не лезть в карман за ключами и просто снять его голыми руками. Но говорят что с этим есть некоторые нюансы.
У меня проявилось. Я даже тему создал, не поняв что это могло бы блокировать запуск.
www.opennet.ru/openforum/vsluhforumID15/4418
Ума не приложу, какое это приложение могло бы быть. В автозагрузке ничего своего нету, на обоих компьютерах примерно одинаковые пакеты. Может драйвер какой?
Если очень надо выяснить - просмотрите, какие модули изменились в этом ченжсете, там по именам файлов вполне ясно. В принципе именно в драйверы кое-куда это вкрутили, но я только SCSI видел
> Если очень надо выяснить - просмотрите, какие модули изменились в этом ченжсете,
> там по именам файлов вполне ясно. В принципе именно в драйверы
> кое-куда это вкрутили, но я только SCSI виделТы уверен, что в SCSI рандом-ы вот именно во используются, а не "игнорирование некоторых источников энтропии на ранней стадии загрузки" наоборот?
Я буковку i пропустил - имелось в виду iSCSI. Собственно, если вскользь глянуть - то там bluetooth, iSCSI, Ceph именно из явно видимого. ну и кто там где ещё get_random ипользует.
> Пользователи _u_random для генерации "ключей" должны страдать.Сказал пользователь urandom который генерирует оные каждый день так или иначе :)
Если кто не понял - это может тормознуть только при инициализации urandom, на старте. А там, на самом деле, криптографически стойкие ключи не так уж часто нужны. Дальше, как и раньше, urandom при недостатке энтропии использует ГПСЧ.
Это у тех, у кого apt-get не через apt-transport-tor работает. А тем домашним пользователям, у кого не работает, уже ничего не поможет, они безнадёжны.
И зачем тягать подписанные общедоступные пакеты, лежащие на куче зеркал, через Tor?
> И зачем тягать подписанные общедоступные пакеты, лежащие на куче зеркал, через Tor?Чтобы никто е догадался.
> И зачем тягать подписанные общедоступные пакеты, лежащие на куче зеркал, через Tor?А чтобы не информировать атакующего лишний раз.
1) Какой софт у тебя вообще в системе установлен. Это может использоваться для слежки или весьма прицельных атак.
2) Атаковать зная точную версию программы в системе значительно удобнее и проще чем наобум.
3) Пальба факта незаапдейченности системы так и просит сплойта в бубен.А вот каким милым, добрым и хорошим способом транзитные узлы могут использовать знание списка пакетов и их версий - я даже как-то так сходу и придумать не могу. В свете таких соотношений так и просится зарубить этот источник информации. Ни к чему атакующим и прочим шпикам это все знать. Это знание не несет ничего хорошего легитимным владельцам систем.
> Если кто не понял - это может тормознуть только при инициализации urandom, на старте.Давай по честному. Ты когда-нибудь видел такое на практике? И я нет.
Я не поручусь, что не видел. Если на своей домашней десктопной генте я более-менее уверен, что, где и когда происходит, то на ноутбуке с убунтой и wifi/bt/vpn или, паче, андроидфоне - чёрт его знает, когда там что происходит.
> Давай по честному. Ты когда-нибудь видел такое на практике? И я нет.Ну я видел. С неких пор ядро при этом натурально вопит про "uninitialized read" из urandom'а, если энтропии мало.
И если на десктопе среднего пошиба это еще не особо большая проблема и там на такое нарваться не так просто, то вот например на виртуалках, или иногда еще встраиваемых системах с энтропией на старте может быть довольно тухло, по причине небольшого числа источников оной и весьма детерминированного состояния системы на старте и повторяемости процессов при каждой загрузке. А "случайные" числа которые повторяются при каждой загрузке или серии оных выбираются из весьма конечного ассортимента наборов - никому не надо, потому что ведет к попаданию в стиле Debian. Когда атакующие начнут ключи просто угадывать.
На этом феномене основан например метод скоростного выноса WPS на роутерах - в системе мало энтропии, поэтому какой "случайный" PIN задумал роутер атакующие могут угадать не за (в среднем) половину от 9999 попыток, что все-таки требует времени, а за допустим десяток попыток, что позволяет любителям kali и прочего подобного устроить интернет-халяву за счет ничего не подозревающего хомяка даже за время жратвы в кафешке.
Ядро с ASLR тоже должно страдать?
> Ядро с ASLR тоже должно страдать?Нет, конечно. Но те, кто увидел "ключей" в "ASLR", - пусть.
Обратная совместимость не нарушена, подумаешь пару минут повисят.
> блокировки приложений, обращающихся к /dev/urandomэто прикол такой, да? оно ж гарантировалось, что не блокируется!
>> блокировки приложений, обращающихся к /dev/urandom
> это прикол такой, да? оно ж гарантировалось, что не блокируется!говорят же вам - клоуны. Оно еще и не гарантировалось что рандомное.
Я даже знаю, где оно на самом деле было надо больше чем одному анону - в стартапных скриптах openssh (и элементарно обходилось стартом до окончания генерации). Но ниасиляторы bash-скриптов (а systemd-initial-ssh-keys-setup еще не написали) вместо этого пошли портить ядро.
Это ты статейку Greg Kroah-Hartman не читал, где он рассказывал, что /dev/urandom более чем секурен.
> Это ты статейку Greg Kroah-Hartman не читал, где он рассказывал, что /dev/urandom
> более чем секурен.я как-то не вижу его среди авторов этого кода. T.Ts'o, когда его придумал, вполне внятно объяснял, для чего он нужен и почему генераторов два.
То есть отсюда и беда - одни забивают гвоздь микроскопом, другие возводят это в религию, третьи в результате ломают то что новой вере не соответствует. А вы подождите, щас загрузится...щасщасщас...
> systemd-initial-ssh-keys-setupТак вот кто генератор идей для Поттеринга, а то он уже не знает какую подсистему ещё заменить :) Всё жду systemd-x11d.
Недостаточно энтропии -> генератор не выдаёт случайные числа -> останавливается загрузка -> не увеличивается энтропия.
> Недостаточно энтропии -> генератор не выдаёт случайные числа -> останавливается загрузка
> -> не увеличивается энтропия.не сцы, всяких мусорных прерываний даже у нестартовавшей системы вагон и маленькая тележка, пул накапает.
Просто медленно.
> Уязвимость в генераторе случайных чисел ядра LinuxКак я уже имел честь докладывать ранее, эта планета не пригодна для жизни.
> я уже имел честьЧесть она как девственность, но ее нельзя восстановить. Сочувствую тебе, но люди живут, ниче.
>> Уязвимость в генераторе случайных чисел ядра Linux
> Как я уже имел честь докладывать ранее, эта планета не пригодна для
> жизни.Согласен с вами, коллега. Предлагаю скинутся с другими коллегами и коллективно купить у Маска ракету на Марс.
> Согласен с вами, коллега. Предлагаю скинутся с другими коллегами и коллективно купить
> у Маска ракету на Марс.там линукс.
>>> Уязвимость в генераторе случайных чисел ядра Linux
>> Как я уже имел честь докладывать ранее, эта планета не пригодна для
>> жизни.
> Согласен с вами, коллега. Предлагаю скинутся с другими коллегами и коллективно купить
> у Маска ракету на Марс.Лучше скинутся на свободную нардварную реализацию ГСЧ, что бы в USB воткнул, и работает при загрузке с драйвером в ядре, а так же емким и быстро наполняемым пулом внутри железяки. И что бы в продаже на каждом углу по 100 деревянных можно было бы взять. Тогда глядишь и ср.ные разработчики материнок и/или процессоров начнут подтягиваться, а то без волшебного пинка видимо ни как ;)
Хотя USB особого доверия нет, но можно на ходу тестировать поток рандома на корректность.
> нардварную реализацию ГСЧЗары, что ли?
> Лучше скинутся на свободную нардварную реализацию ГСЧ, что бы в USB воткнул,
> и работаетСкинуться? http://altusmetrum.org/ChaosKey/
https://store.vikings.net/chaoskey?search=chaoskey
Да, это ж скока в чанораминах-то будет! Ах, кровопивцы. Хоть рассточка-то у них есть??И ведь по сети https://geektimes.com/company/mailru/blog/295353/ "во время загрузки" (да-а?!) не постучишься... Беда!
при загрузке с драйвером в ядре, а так же
> емким и быстро наполняемым пулом внутри железяки. И что бы в
> продаже на каждом углу по 100 деревянных можно было бы взять.
> Тогда глядишь и ср.ные разработчики материнок и/или процессоров начнут подтягиваться,
> а то без волшебного пинка видимо ни как ;)
> Хотя USB особого доверия нет, но можно на ходу тестировать поток рандома
> на корректность.
Да без проблем, FST-01 в помощь, и скидываться не надо. а на неё - NEUG. Который, впрочем, может жить на куче других железок с STM32.
> Лучше скинутся на свободную нардварную реализацию ГСЧ, что бы в USB воткнул,Воткни в usb wifi свисток на ath9k и разреши собирать энтропию с его ADC в конфиге ядра. Получишь вагон энтропии. При том в случае ADC бэкдор всучить особо некуда, да и ядро не напрямую это трескает все-же. А прошивка там опенсорсная как раз. Древняя проприетарная небось и не умеет отсчеты ADC наружу из свистка вытаскивать.
В "свободной реализации" воткнутой в usb - один хрен будет скорее всего ADC. А где там еще энтропию особо брать? С "крутого и правильного" хардварного генератора случайных чисел? Лол!
/dev/random не подвержен? Расходимся.
Это не от этого ў меня ядро ck 4.16.6 не стартует DE, пока рандомные клавіші несколько раз не понажімаю?
Скорее всего, да.
> Это не от этого ў меня ядро ck 4.16.6 не стартует DE, пока рандомные клавіші несколько раз не
> понажімаю?подожди пару часиков, ничего не нажимая и мыша не шевеля - если оно все же стартанет - да, оно.
Багрепорт - майнтейнеру дистрибутива, Линуса оно не интересует, у него палец.
> подожди пару часиков, ничего не нажимая и мыша не шевеля - если
> оно все же стартанет - да, оно.
> Багрепорт - майнтейнеру дистрибутива, Линуса оно не интересует, у него палец.У майнтайнеров чего доброго тоже палец может оказаться - системда нынче видите ли умеет random seed между перезагрузками сохранять и скармливать ядру, во избежание подобных приколов. А если кто хотел быть самым умным - так пусть и простреленную пятку сам лечит.
{sarcasm} 105 бит энтропии... блин, да, это очень-очень мало... {/sarcasm}
как у пароля из 16 символов
Так в какой версии ядра исправлено?
Пользователь с именем Urandom+(чего-то_там_случайное) может залогиниться в системе на ранних стадиях загрузки системы из за низкой энтропии :)
Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы и не позиционируется как криптостойкий источник. О чём вообще писк-то?
> Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы
> и не позиционируется как криптостойкий источник. О чём вообще писк-то?Секьюрити сёркус снова в городке Линуса нашего Тормальдса. С новыми поэтессами из Гран Гугле Опера.
> Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы
> и не позиционируется как криптостойкий источник. О чём вообще писк-то?Я, конечно, иронизировал над сабжом и ключами-криптографией, но...
...изменение апи, как то блокировка чтения /urandom (как коллеги и указывали выше, да) , удариро по вот моему ныне любимому GNU GuixSD: https://debbugs.gnu.org/31268 .
Они там занимаются "авангардом" в виде системных тестов (тесты разлиных конф.системы - после установки в VM) -- и вот как раз на _установке_ в VM оно замерзает [вроде, как] намертво на "простой" генерации UUID-а при создании раздела parted-ом. В виртуалке во время загрузки, видимо, с источниками рандома туго. Совсем то есть.
//BTW, коллеги, как вовнутрь QEMU "пробрасывать" немного рандома из родительской системы?
--
https://lists.gnu.org/archive/html/help-guix/2018-05/msg0013...
https://lists.gnu.org/archive/html/help-guix/2018-04/msg0021...
>> Низкая энтропия на минуту при загрузке? В /dev/urandom?!!! Так оно как бы
>> и не позиционируется как криптостойкий источник. О чём вообще писк-то?
> Я, конечно, иронизировал над сабжом и ключами-криптографией, но...
> //BTW, коллеги, как вовнутрь QEMU "пробрасывать" немного рандома из родительской системы?Не-rtfm с мойе стороны. Sorry за шум.
https://wiki.qemu.org/Features/VirtIORNG$ man qemu-system-i386 2>/dev/null |grep rng
-object rng-random,id=id,filename=/dev/random
reference this entropy backend from the virtio-rng device. The filename
-object rng-egd,id=id,chardev=chardevid
will be used to reference this entropy backend from the virtio-rng
$ _