Разработчики проекта OpenBSD выпустили (http://marc.info/?l=openbsd-announce&m=140550655018712&w=2) обновление переносимой редакции пакета LibreSSL 2.0.2 (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. В новом выпуске устранена недоработка (https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_...), которая может привести к серьёзным проблемам с безопасностью на платформе Linux.Проблема связана с особенностью реализации в LibreSSL генератора псевдослучайных чисел (PRNG), который был завязан на возможности OpenBSD и не учитывал некоторые особенности платформы Linux. В частности, LibreSSL использовал изменение PID для отслеживания форков и инициирования переинициализации PRNG, но не учитывал, что один 16-разрядный PID-идентификатор может быть назначен двум и более ответвляемым процессам. В Linux гарантируется, что ответвлённые дочерние процессы будут иметь всегда разные PID, но допускается, что при определённых условиях PID может совпасть с идентификатором прародителя (после большого числа форков можно добиться совпадения PID дочернего процесса и прародителя).
В OpenSSL присутствует специальный код для отслеживания данной ситуации, но данный код был удалён в LibreSSL, так как он был неактуален для OpenBSD. В процессе создания переносимого варианта LibreSSL особенности формирования PID в Linux выпала из внимания разработчиков. Учитывая данную особенность исследователи безопасности подготовили тестовую программу (https://gist.github.com/AGWA/eb84e55ca25a7da1deb0), которая продемонстрировала возврат двух одинаковых значений при разных обращениях к генератору псевдослучайных чисел LibreSSL. Разработчики OpenBSD считают проблему раздутой и малоприменимой в реальных условиях. В частности, Bob Beck указывает на то, что недоработка является проблемой только автора демонстрирующей уязвимость тестовой программы, реальные приложения никогда не функционируют подобным образом.Проанализировав возникшие в результате обсуждения проблемы и сомнения (http://port70.net/~nsz/47_arc4random.html) в корректности применения обходных путей для защиты от их проявления, Theodore Ts'o предложил (http://lists.openwall.net/linux-kernel/2014/07/17/235) включить в состав ядра Linux новый системный вызов getrandom, который является аналогом системного вызова getentropy, присутствующего в OpenBSD. Getrandom предоставит надёжную защиту от атак, основанных на исчерпании доступных файловых дескрипторов (при остутствуии свободных десктипторов невозможно задействовать /dev/urandom и активируется запасной вариант, использующий менее надёжный PRNG).
URL: http://threatpost.com/overblown-libressl-prng-vulnerability-...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40227
Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD. Хотите, чтобы на других платформах нормально работало? Поддерживайте в своей ОС фичи из OpenBSD, и будет работать! Вот такая вот переносимость по-Теодоровски, ага..
> Поддерживайте в своей ОС фичи из OpenBSD, и будет работать! Вот такая вот переносимость по-Теодоровски, ага..Собственно есть и строго обратная сторона: линуксизмы в софте, которые остальным приходится заменять. Если цель не холиварить, то очевиден выход. Кто заинтересован в портировании под свою платформу, тот и отслеживает такие моменты. Под BSD с солярки перетащили ZFS, да и под линукс втащили. Заменяя ОС-зависимые моменты. Пока никто не умер. Тем более у линукс разработчиков явно поболе, так что ситуация более выигрышная. Короче, отставить панику, всё ок.
Это сплошь и рядом. Posix совместимость давно линуксоидов не интересует. Лепят все что Лукавый в голову стрельнет...
> Это сплошь и рядом. Posix совместимость давно линуксоидов не интересует.Как видим, бздельники ничем не лучше в этом плане.
> Лепят все что Лукавый в голову стрельнет...
Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там лепят ни с чем не совместимые нетграфы, геомы, kqueue и что там еще. И это вроде как нормальным считается...
1. А ты никогда не задумывался что некоторые специфические фичи работающие по другую сторону от kernel (предположим что справа World, в центре kernel, слева netgraph и драйвера) не нужно запихивать в стандарт, даже Posix. Так как абстракция вызова (posix совместимая) функций ядра все равно прикроют подсистемы и очереди слева.
А в данном случае Линуксоиды именно и World и калечат, делая его вообще несовместимым с остальными Unix compatible системами.
Теперича netgraph. К этой подсистеме вообще Wоrldу прямой доступ не нужен, да его практически нет. И Если-бы ты чето понимал в этом - так не написал бы своей глупости.
Хорош уже в лужу пердеть... Свинство разводить :)
2. Netgraph мощнейщий инструмент, правда не для лодырей устанавливающих бинарные пакеты. Там внутренний Netgraph-"ассемблер" знать надо, чтобы чтото родить.
> Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там
> лепят ни с чем не совместимые нетграфы, геомы, kqueue и что
> там еще. И это вроде как нормальным считается...А да и Лукавый - это сатана а не чертенок со сковородой, который походу у многих Линуксоидов тут мягкое место подогревает. Да так что минусовать начинают даже не прочитав пост :)
>> Лукавый в кедах - эмблема другой системы, обломитесь. И таки да, там
>> лепят ни с чем не совместимые нетграфы, геомы, kqueue и что
>> там еще. И это вроде как нормальным считается...
> А да и Лукавый - это сатана а не чертенок со сковородой,
> который походу у многих Линуксоидов тут мягкое место подогревает. Да так
> что минусовать начинают даже не прочитав пост :)У деревни Крюково - ВИА Пламя :) BSDшики :)
> Собственно есть и строго обратная сторона: линуксизмы в софте, которые остальным
> приходится заменять.Ну вон KMS+DRM стали новым стандартом взаимодействия ядер с юзермодом по части графики, не развалились. Почему оно в обратную сторону не должно работать, если некто хорошую идею подал - интересный вопрос. Наверное ЧСВ и NIH синдром надо строить, чтобы не вело к контрпродуктивным результатам.
> Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD.На чём работать умеют, на то и затачивают.
> На чём работать умеют, на то и затачивают.Прекрасно, но зачем тогда было втирать очки про портабельность? Тогда systemd - тоже вполне портабельная программа.
>> На чём работать умеют, на то и затачивают.
> Прекрасно, но зачем тогда было втирать очки про портабельность? Тогда systemd -
> тоже вполне портабельная программа.Попробуйте скомпилировать и протестировать LibreSSL на своём линуксе. Есть хороший шанс, что это получится вообще без допиливания чего-либо.
А потом сделайте то же с systemd в OpenBSD/NetBSD/MacOS X.
И вот только после этого что-то заявляйте.
>> Ага, обещали "переносимую версию", а реально все затачивают под особенности OpenBSD.
> На чём работать умеют, на то и затачивают.На самом деле, всё сделано просто: LibreSSL использует всё, что ему нужно, а если в искомой ОС (не-OpenBSD) нет каких-то возможностей, то при сборке подключается необходимая "добавка" кода. Таким образом имеем читаемый (ergo, понятный, ergo, менее грабельный) код и при этом хорошую переносимость. Именно таким образом организованы остальные дочерние проекты OpenBSD, и на их портабельность, вроде, особо не жалуются.
А разработчики LibreSSL выпустили уже 2.0.3. :)
Мало что-ли /dev/random и /dev/urandom устройств?
> Мало что-ли /dev/random и /dev/urandom устройств?Ага, и оба - не аппаратные.
> и оба - не аппаратныеи оба неаппаратные
двоечник. :)"не аппаратные" -- раздельно.
слово "неаппаратные" (слитно) -- тоже существует, но в данном случае нужно не оно.
> двоечник. :)
> "не аппаратные" -- раздельно.
> слово "неаппаратные" (слитно) -- тоже существует, но в данном случае нужно не оно.Программер отъымэл филолога =)
Да Grammar_Nazi, срочно прими таблетку Даля и клизму Ожегова.
да, павлуша окончательно деградировал: xasd «программером» считает. осталось теперь подвальных бомжей в интеллектуалы записать — и будет совсем хорошо.
> Ага, и оба - не аппаратные.И это хорошо. Ибо на слово верить американскому дяде Сэму и его АНБ - нафиг надо!
Точно, у меня в проекте чип имеет аппаратный генератор. Вся информация - это одна строчка в описании регистра:
31:0 random_number R 0xXXXXXXXX This register contains a random 32 bit number which is
computed each time it is read.
О качестве генератора можно только догадываться.
"что ли", ёпта
> Мало что-ли /dev/random и /dev/urandom устройств?согласен (особой надобности в этом getrandom нет)..
хочу сказать что, если в самом начале (фаза инициализации) открыть файловый дескриптор связанный с /dev/(u)random ,
то потом уже хоть 20 раз можно делать форки, и исчерпывать различные ресурсы свобоных файловых дескрипторов...
всё равно уже открытый файловый дескриптор -- будет функионировать и клонироваться нормально.
особой надобности в этом getrandom нет -- но если сделают это -- хорошо. пусть будет :) ..
а что делать вновь запускаемым процессам? или процессы использующие криптографию должны запускаться строго из инит? лимит он такой.. в любой момент могли сказать ой.. при запуске очередного apache демона использующего ssl к примеру..
Открывать /dev/urandom (а потом уже всё остальное)
> Открывать /dev/urandom (а потом уже всё остальное)а точно php/питон/чтотам придумаешь - будет знать что будет работать именно с криптографией? у него доступа в /dev/astral нету.. угадывать по звездам еще не научился.. Да и держать лишний открытый дискритор из расчета - а вдруг что-то потребуется - это уже перебор.
> а что делать вновь запускаемым процессам?Если процессу не хватило дескрипторов - там в общем случае даст дуба отнюдь не только криптография.
Умирать на старте, разумеется
зачем умирать когда можно работать? Не считая того что вызов syscall сильно дешевле чем open + read + close...
Только read считай :-) .. open только один раз, а close вообще не надо (fd закроется автоматом при закрытии процесса)
> а что делать вновь запускаемым процессам? или процессы использующие криптографию должны
> запускаться строго из инит? лимит он такой.. в любой момент могли
> сказать ой.. при запуске очередного apache демона использующего ssl к примеру..Проблема вроде банальная, а самом деле гиморрой сильнейший!
Решений несколько, одно глобальное - делать /dev/random частью псевдодевайсов: STDIN, STDOUT, STDERR и добавить STDRND.
STDRND (плюс к SDTIN, STDOUT, STDERR) -- это было бы отличной идеей.накладных расходов это практически не добавит, а вот польза большая (куча программ используют случайные числа и чуть меньше программ -- крипографию).
Открою страшную тайну: счётчик открытых файловых дескрипторов уменьшается при создании процесса.
Это чо за талант? o_0 Мож увеличивается?
> Мало что-ли /dev/random и /dev/urandom устройств?И оба неприемлимы к использованию в криптографии.
> И оба неприемлимы к использованию в криптографии.С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого переламерит"?
> С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого
> переламерит"?нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.
не стоит обращать внимания: это существо феерически тупое во всём, о чём говорить пытается.
> нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не
> знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.Капитан Очевидность спешит на помощь! Ну спасибо, Кэп, я подозревал :). Но до последнего момента надеялся что межушный нервный узел оппонента все-таки немного включится.
> не стоит обращать внимания: это существо феерически тупое во всём
Знаешь, Кэп, иногда достаточно посмотреть на ник и его написание чтобы многое осознать еще далеко на подлете. Так что я на самом деле всего лишь пытался потыкать корм палочкой на самом деле :)
> до последнего момента надеялся что межушный нервный узел оппонента все-таки немного
> включится.я пробовал и добрыми словами, и словесными пинками. неа, там военно-полевая облегчённая модель, умеет только базовые функции.
да да. о компрометации /dev/random забыли ?http://everything2.com/title/Compromising+%252Fdev%...
все еще можно использовать после этого в криптографии?
всё-таки я не понимаю, как можно жить на свете с таким идиотизмом.
Я одного не понимаю, как ты живешь с генератором случайных чисел от таймера CPU.. Хотя да, заметны систематические излияния гамна по /dev/random :)
> Я одного не понимаю, как ты живешь с генератором случайных чисел от
> таймера CPU.. Хотя да, заметны систематические излияния гамна по /dev/random :)u забыл... Но недалеко ушел
молодец, чётко свой идиотизм демонстрируешь.
А PRNG можешь засунуть себе в одно место и проворачивать... Регулярно будешь замечать PSEUDORANDOM мушку
>> нет, это просто написавший — идиот, который совершенно ничего (кроме названий) не
>> знает про криптографию, prng для криптографии и реализацию /dev/random и /dev/urandom.
> Капитан Очевидность спешит на помощь! Ну спасибо, Кэп, я подозревал :). Но
> до последнего момента надеялся что межушный нервный узел оппонента все-таки немного
> включится.да да. за одно объясни почему их аж 2 рандома :-) и вспомни дыры в реализации датчиков случайных чисел которые находили в ядре.. забыл? так гугл в помощь.. после таких дыр ты точно согласен использовать данные напрямую ?
>> С чего бы это вдруг? У нас тут сегодн чемпионат "кто кого
>> переламерит"?
> нет, это просто написавший — идиот,как легко оскорблять другие мальчик. выучил уже уроки? понахватался на улице словечек? или мама не научила хорошим манерам? хорошие же у тебя родители были..
Ура! Хорошая штука. Нужно!
Может посмотрим по-другому, оказывается в линуксе могут существовать и выполняться 2-а процесса с одинаковым PID, это фича или бага ядра...
не могут.
>> не могут.А как же это
В Linux гарантируется, что ответвлённые дочерние процессы будут иметь всегда разные PID, но допускается, что при определённых условиях PID может совпасть с идентификатором прародителя (после большого числа форков можно добиться совпадения PID дочернего процесса и прародителя).
для этого прародитель должен завершиться до этого. PID всего ничего, их приходится повторно использовать.
> Может посмотрим по-другому, оказывается в линуксе могут существовать и выполняться 2-а
> процесса с одинаковым PID, это фича или бага ядра...тоже мне синсация :-) ..
два разных процесса с одинаковым pid -- существовать могут. это же ясно как ясный день! но просто не одновременно..
однако подозреваю что любители bash-говноскриптов в шоке:
kill -- `cat /run/my_program.pid` # может случайно убить не того кого нужно было
таким образом, система sysvinit -- способна изредка делать фэйлы на пустом месте (и это не баг, а фича ядра.. то есть sysvinit и ядро linux -- заведомо спроектированы таким образом что sysvinit будет иногда глючить)..
а вот с systemd -- такого бы не случилось бы.
особенно в ситуации когда демон использует внутри своей инициализации -- функцию sd_notify из <systemd/sd-daemon.h> ..
А где он по крупному соврал? PID файлы могут указывать на посторонний PID, если например программа внепланово завершилась. При сильном желании это можно обнаружить, но большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.
вот если бы он остановился на констатации фактов и не писал свои идиотические домыслы…
> большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.именно так.
вероятность этого события очень низкая -- но всё же эта вероятность есть -- до тех пор пока состояние процесса демона НЕ сохраняется в его родительском процессе (и оно как раз не сохраняется в sysvinit . сохраняется лишь pid-номер внутри текстового файла).
>> большинство скриптов писаны левой пяткой и реально могут прибить другой процесс, если его угораздит pid занять.
> именно так.
> вероятность этого события очень низкая -- но всё же эта вероятность есть
> -- до тех пор пока состояние процесса демона НЕ сохраняется в
> его родительском процессе (и оно как раз не сохраняется в sysvinit
> . сохраняется лишь pid-номер внутри текстового файла).Врёшь, ламерок. service stop смотри не только на $PID, но и на /proc/$PID/{comm,stat}. Так что совпадение только по $PID - не прокатывает.
> service stop смотрит не только на $PID, но и на /proc/$PID/{comm,stat}все говно-bash-скрипты проверил? :-)
некоторые вообще по killall убивают (даже не глядя на pid).
да, sysvinit провоцирует делать плохие решения.
так вызов включили или только предложили включить?
>>Getrandom предоставит надёжную защиту от атак, основанных на исчерпании доступных файловых дескрипторов.
> как все сложно с ПО.Fixed.
> Fixed.Админь метлу или ящики - там попроще.
Ну merge window сейчас, вообще-то, закрыто.
[сарказм]Почему бы не выпустить ещё один форк?[/сарказм]
> невозможно задействовать /dev/urandom, поэтому библиотеками активируется
> запасной вариант, использующий менее надёжный PRNG.Это называется "горе от ума".