В драйвере n_hdlc, поставляемом в составе ядра Linux, выявлена (http://openwall.com/lists/oss-security/2017/03/07/6) уязвимость (CVE-2017-2636 (https://security-tracker.debian.org/tracker/CVE-2017-2636)), позволяющая локальному пользователю повысить свои привилегии в системе. Вызывающая уязвимость ошибка присутствует (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... в ядре с 22 июня 2009 года. Подготовлен рабочий прототип эксплоита, который будет опубликован через несколько дней, чтобы дать пользователям время на обновление системы.Уязвимость вызвана состоянием гонки (race condition) при доступе к указателю n_hdlc.tbuf, которое может привести к двойному освобождению памяти и перезаписи не связанных с буфером данных через манипуляцию с параметрами протокола HDLC (https://ru.wikipedia.org/wiki/HDLC) (High-Level Data Link Control). Проблема выявлена в результате изучения причин краха ядра, инициированного при выполнении fuzzing-тестировния системных вызовов программой syzkaller (https://github.com/google/syzkaller). Для совершения атаки непривилегированный локальный пользователь может активировать HDLC для устройства tty, при этом модуль ядра n_hdlc будет загружен автоматически. Для успешной атаки не требуется наличие специализированного оборудования Microgate или SyncLink.
Наличие уязвимости подтверждено в ядрах из RHEL 6/7 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2636), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1430049), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-2636), Debian (https://security-tracker.debian.org/tracker/CVE-2017-2636) и Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2... ядро RHEL 5 проблеме не подвержено. Обновление пакетов с устранением уязвимости пока выпущено только для Ubuntu (https://www.ubuntu.com/usn/usn-3221-1/) и Fedora Linux (https://bodhi.fedoraproject.org/updates/FEDORA-2017-387ff46a66). Исправление также доступно в виде патча (https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/....
В качестве обходного пути защиты можно блокировать автоматическую загрузку модуля n_hdlc, добавив строку "install n_hdlc /bin/true" в файл /etc/modprobe.d/disable-n_hdlc.conf. Если модуль n_hdlc уже загружен и используется, то для его выгрузки требуется перезагрузить систему.URL: http://openwall.com/lists/oss-security/2017/03/07/6
Новость: http://www.opennet.me/opennews/art.shtml?num=46164
только недавно закрыли дыру в dccp, и тут опять. тащить все левые драйвера в ядро уже не кажется такой хорошей идеей.
Да это никогда не казалось хорошей идеей. Просто так исторически сложилось.
Не знаю, не знаю. Как-то вон, к примеру, винда, в которой "исторически сложилось" иначе к тому же самому пришла. Максимум драйверов в поставке, более-менее работа на всем, что можно из коробки (пока не везде выходит, производители закрытых драйверов сопротивляются иногда, но в целом явно туда идет), поставки обновления через win update.В современных компьютерах удобство пользователя, желающего, чтобы "просто все работало" поставлено во главу. И, строго говоря, это не так плохо - предположение, что суровые дяди из компании, создающий ОC/дистрибутив, лучше конечного пользователя знают, какие драйверы ему на самом деле нужны дает лучший результат, чем предложение "ставить то, что идет с железкой". И в плане совместимости, и в плане безопасности. Ну а для хорошо разбирающихся или сложных ситуаций оставлен механизм, когда у поставленного отдельно драйвера приоритет больше, чем у системного - и в линуксе есть, и в винде.
(да и вендоры остальных ОС - FreeBSD какой-нибудь или Solaris, к примеру, тоже постоянно в релиз нотах хвастаются, как очередные драйверы добавили/обновили).
Авторы postgresql такое не практикуют
дuстроклепатели на знают какой у вас набор железа, поэтому тащут всё.Такая вот я Линyпcа "архитектура".
// b.
Сделай лучше.
При этом ровным счетом ничего не мешает пересобрать ядро отключив полностью ненужные тебе модули. Более того, существуют дистры, где такие действия являются нормой. Вот такая у линукса архитектура.
> При этом ровным счетом ничего не мешает пересобрать ядро отключив полностью ненужные
> тебе модули. Более того, существуют дистры, где такие действия являются нормой.
> Вот такая у линукса архитектура.Так это целиком заслуга GPL'а. А архитектура у Линукса довольно фиговая - кубик-рубик-монолит. Но открытость кодов и коммунистический метод разработки повышают производительность труда на порядки, позволяя даже такой допотопной архитектуре легко уделывать более продвинутые, но закрытые разработки.
Пример "продвинутых" закрытых разработок в студию!
> Пример "продвинутых" закрытых разработок в студию!Windows ?
которое(ая) с флопповодом не научилась нормально работать за всё время его существования?
> которое(ая) с флопповодом не научилась нормально работать за всё время его существования?"нормально", это как ?
>> которое(ая) с флопповодом не научилась нормально работать за всё время его существования?
> "нормально", это как ?читать и соблюдать собственные заголовки, не долбиться с лошадиными таймаутами в отключенные в биосе устройства. да даже тупо показывать адекватное количество дисководов.
Так этож в линуксе - у меня физически не было флоппика, а blkid подвисал на несколько секунд, а потом выдавал, что fd0 не найден.
> Так этож в линуксепоставь пожалуйста галочки в первой сотне дистров, где ты сталкивался с этой проблемой.
> blkid подвисал на несколько секунд, а потом выдавал, что fd0 не найден.
вот всё так у опенсорц пионЭров, не могут переплюнуть профеЙ в тормозах. у проприетарных профи XP в несуществующий привод колотилась минуту-полторы.
> у проприетарных профи XP в несуществующий привод колотилась минуту-полторыДоказательства словам есть?
Подтверждаю, всё так. Поставь в виртуалке да посмотри.
XP установлена не в виртуалке - никаких ложных дисководов нет.
> Доказательства словам есть?какие тебе доказательства нужны, болезный?
> Так этож в линуксе - у меня физически не было флоппика, а
> blkid подвисал на несколько секунд, а потом выдавал, что fd0 не
> найден.# time blkid
{skip}
real 0m0.007s
user 0m0.001s
sys 0m0.006sфлопика нет
>> которое(ая) с флопповодом не научилась нормально работать за всё время
>> его существования?
> "нормально", это как ?Не вспоминая тот самый анекдот: https://geektimes.ru/post/188554/ (да, я дочитал до конца).
> Не вспоминая тот самый анекдот: https://geektimes.ru/post/188554/ (да, я дочитал до конца).Ну NT не подвисала. Хотя про лошадиные таймауты гражданин пишет правду. С другой стороны, я не сталкивался с тем, чтобы под NT был левый дисковод.
> Windows ?В своё время были всякие Tru64, AIX, Solaris. Даже Minix в определённый момент была более продвинутой системой, чем Linux.
>> Windows ?
> В своё время были всякие Tru64, AIX, Solaris. Даже Minix в определённый
> момент была более продвинутой системой, чем Linux.За других не скажу, но AIX?!.. Да ты о нем только слышал, наверное. Это же Windows в UNIX'ах со своим регистром и пр.
Я работал практически со всеми *NIX'ами, но более т.у.п.о.й системы не знаю... :)
> За других не скажу, но AIX?!Я с этим дерьмом сейчас работаю. То, что это адовое дерьмо не отменяет факта, что в 1998-м году оно было значительно серьёзнее Линукса.
> Я с этим дерьмом сейчас работаю. То, что это адовое дерьмоХм... и чем же AIX вам такое уж "дерьмо"?
Всё при нём, и разумно вроде устроено.
>> Пример "продвинутых" закрытых разработок в студию!
> Windows ?Тут явно неадекват. Ну для тебя может и уиндоус
ПС. Ник смени, а то выглядишь как со справкой здоров от психиатра...
>>> Пример "продвинутых" закрытых разработок в студию!
>> Windows ?
> Тут явно неадекват. Ну для тебя может и уиндоус
> ПС. Ник смени, а то выглядишь как со справкой здоров от психиатра...Он как Клоун, только Адекват.
> Так это целиком заслуга GPL'а.То есть ты считаешь, что для отключения модулей надо открывать исходники и ручками удалять весь их код?
1. Убери лишние модули из ntoskrnl.2. Распространи свою версию среди всех желающих.
Вам, может, и ничего не мешает на локалхосте вашем. А у некоторых есть строчка в лицензионном соглашении, где говорится, что саппорт в отношении систем с самособранными ядрами предоставляться не будет. А ради сапорта систему (шапку) и выбирали
Вы не понимаете разницу между самим наличием возможности и решением о ее использовании? А между архитектурой ядра и лицензионным соглашением?
> Вам, может, и ничего не мешает на локалхосте вашем. А у некоторых
> есть строчка в лицензионном соглашении, где говорится, что саппорт в отношении
> систем с самособранными ядрами предоставляться не будет. А ради сапорта систему
> (шапку) и выбиралиНу дык решение простое - не использовать шляпу.
> дuстроклепатели
> "архитектура"И часовню -- тоже Вы.
Михаил, вот Ubuntu и Fedora уже фактически исправили проблему. А почему в этом списке я не вижу Альт? Не вброса ради...
Потому что источник новости зарубежный.
Потому что "для Альта неактуально".
> Михаил, вот Ubuntu и Fedora уже фактически исправили проблему.
> А почему в этом списке я не вижу Альт? Не вброса ради...Пока объезд blacklist'ом:
echo "blacklist n_hdlc" >> /etc/modprobe.d/blacklist-n_hdlc.conf
grep -w n_hdlc /proc/modules && echo reboot NOW
> только недавно закрыли дыру в dccp, и тут опять. тащить все левые
> драйвера в ядро уже не кажется такой хорошей идеей.Да и "состояние гонки" тоже уже было.
$ grep HDLC .config; echo $?
1Щастье.
// b.
$ zgrep HDLC /proc/config.gz || echo Щясте
Щясте
>gzip: /proc/config.gz: No such file or directory
>ЩястеНекорректный скриптец
Корректный, если ядро собрано с поддержкой CONFIG_IKCONFIG_PROC
> Корректный, если ядро собрано с поддержкойЖдём уязвимости в! >>>
:>CONFIG_IKCONFIG_PROC
Подготовлен рабочий прототип эксплоита, который будет опубликован через несколько дней, чтобы дать пользователям время на обновление системы.Уязвимость вызвана состоянием гонки (race condition) при доступе к указателю n_hdlc.tbuf, которое может привести к двойному освобождению памяти и перезаписи не связанных с буфером данных через манипуляцию с параметрами протокола HDLC (High-Level Data Link Control). В случае ошибки передачи данных, одновременный вызов функций flush_tx_queue() и n_hdlc_send_frames() может привести к дублированию записи указателя n_hdlc.tbuf в список tx_free_buf_list и дальнейшему двойному освобождению памяти одного и того же буфера в функции n_hdlc_release().
-------------------
Может я чего-то не понимаю, но почему они сначала заявляют что дают время на обновление и тут же объясняют как провести атаку. Да это не готовое решение, но кому надо - взломает. Публиковали бы и эксплоит тогда сразу
> Может я чего-то не понимаю, но почему они сначала заявляют что дают
> время на обновление и тут же объясняют как провести атаку. Да
> это не готовое решение, но кому надо - взломает. Публиковали бы
> и эксплоит тогда сразуКому надо - может и по исправляющему патчу понять и в чём проблема, и напишет эксплоит.
Может патчи тогда не публиковать?
> Может я чего-то не понимаю, но почему они сначала заявляют что дают время на обновление и тут же объясняют как провести атаку. Да это не готовое решение, но кому надо - взломает.Чтобы взломать без эксплоита надо написать этот эксплоит. А на это уйдёт время. Данное объяснение на самом деле, только выглядит законченным объяснением, да и то, только для того, кто не пытался эксплуатировать уязвимости. Всё что объяснено -- это как можно получить exploitable double free. Допустим, что объяснено достаточно внятно и при попытке спровоцировать этот дабл-фри проблем не возникнет. Но как эксплуатировать этот дабл-фри? Это потребует отдельных исследований, которые потребуют нескольких часов, а то и суток.
А возможность использовать только авторизированным пользователем снижает ценность быстрого получения эксплоита. Просто аккуратненько допишут в базу для использования в случае попадания в систему.
> Может я чего-то не понимаю, но почему они сначала заявляют что дают
> время на обновление и тут же объясняют как провести атаку.1. Для толковых объяснение содержится в патче. Поэтому просто умалчивать не поможет.
2. Если не объяснять, как взломать, могут подумать, что это ложная тревога. В конце-концов, граждане безопасники "ставят на уши" миллионы людей этим заявлением. Поэтому надо его как-то убедительно подкреплять.
Продолжим тему вынесения драйверов на пользовательский уровень в отдельное адресное пространство?
Если ты про userland, то принципиально ничего не поменяет, привилегии рута будут получены. Если про запуск драйверов от пользователя, то тогда и ломать особо ничего не надо, запустил себе драйвер винчестера и сразу всё поимел без всяких эксплоитов.
> Если ты про userland, то принципиально ничего не поменяет, привилегии рута будут
> получены.С какой радости? У всяких сетевых модулей не будет доступа к таблице процессов, чтоб там UID менять в обход API.
> Если про запуск драйверов от пользователя, то тогда и ломать
> особо ничего не надо, запустил себе драйвер винчестера и сразу всё
> поимел без всяких эксплоитов.Дык счас то всё ровно так же лежит: и ядро, и модули. Бери запускай. Но почему-то просто так к винту доступ это не даёт...
> С какой радости? У всяких сетевых модулей не будет доступа к таблице процессов, чтоб там UID менять в обход API.А зачем его менять то? Сам модуль выполняется с привилегиями рута, эксплоит позволяет заставить модуль выполнить произвольный код.
> Дык счас то всё ровно так же лежит: и ядро, и модули. Бери запускай.Что правда что-ли? Ну сделай мне modprobe или insmod от пользователя
> А зачем его менять то? Сам модуль выполняется с привилегиями рута, эксплоит
> позволяет заставить модуль выполнить произвольный код.Речь не об адр. пространстве ядра, а отдельном (как в микроядре). И привилегии рутовые тоже не нужны в таком случае. Достаточно пользовательских.
Но т.к. пока что всё живёт именно в одном пространстве - то и получается: левая пятка может отдать рута кому ни попадя.
> Что правда что-ли? Ну сделай мне modprobe или insmod от пользователяВам же Вашими же слова:
"Если про запуск драйверов от пользователя..."
Ну предположим, что есть микроядро и драйвера в отдельном пространстве. Такие как драйвера клавиатуры, монитора и жестких дисков. Находится уязвимость в любом из них, позволяющая выполнить произвольный код. Внимание, вопрос: "и чем вам помогло отдельное адресное пространство и отсутствие рутовых привилегий?"
Ядро в своём адресном пространстве, каждый из драйверов в своём. Общение друг с другом через стандартизированный API.Ошибка в драйвере приведёт к перезапуску драйвера.
Обычно здесь новички задают вопрос "Как перезапустить драйвер жёсткого диска, если нет доступа к жёсткому диску?" Отвечаю: программы уже давно разделены на сегменты кода (только чтение, у всех, вкл. саму программу) и сегменты данных (чтение и запись). Точка входа в драйвер не изменилась. Для перезапуска будет повторно вызвана функция начальной инициализации, которая заново найдёт диск, инициализирует его и настроит все параметры.
Ни один из драйверов не нуждается в рутовых правах или правах нулевого кольца. Скажу даже больше: современные процессорные прерывания уже давно ничего не прерывают. Они записывают байт в оперативную память, показывающий, что прерывание пришло. Затем диспетчер прерываний ОС находит какие прерывания пришли и какие драйвера нужно при этом вызвать, а драйвер уже сам решает что делать дальше.
То есть ты даже не понял, почему я назвал именно эти три драйвера. Браво. Настоятельно советую тебе не рассуждать на тему безопасности.
Безопасность и всего 3 драйвера? Нет слов.
Я даже не хочу тебе говорить, что драйвера делятся на драйвера физических устройств и драйвера-фильтры (они же "промежуточные"). Вторых больше.
> То есть ты даже не понял, почему я назвал именно эти три
> драйвера. Браво. Настоятельно советую тебе не рассуждать на тему безопасности.Вообще-то, безопасность остаётся на уровне.
Возможно, Вы хотели подколоть на тему устойчивости?
Типа, без драйвера винта сам драйвер не загрузится с винта же. Да, смешной пример,
особенно с учётом кеша в драйвере файловой системы.Попробуйте залить на флешку /bin/ls, запустить его оттуда(!) /mnt/flash/ls
и затем безо всяких команд просто вынуть флешку (имитация мгновенной недоступности винта)
и пусканите /mnt/flash/ls ещё раз.
> Вообще-то, безопасность остаётся на уровне.А если подумать? Хорошенько подумать. Только не в ключе "микроядро - серебряная пуля", а в ключе "какой именно код захотел бы выполнить взломщик для каждого их этих драйверов".
> Возможно, Вы хотели подколоть на тему устойчивости?Нет. Но данный вопрос и дальнейший текст наводит на мысль, что ты вообще не пытаешься думать, ты ищешь что-то знакомое в вопросах и выдаешь штампованные ответы.
> А если подумать? Хорошенько подумать. Только не в ключе "микроядро - серебряная
> пуля", а в ключе "какой именно код захотел бы выполнить взломщик
> для каждого их этих драйверов".А... Хорошенькоподумавший снова занимается подменой тезиса.
Тему
"из-за одного уязвимого сервиса не страдает безопасность остальных"
пытается подменить на
"микроядро должно обеспечивать безопасность каждого, даже дырявого, сервиса в отдельности".
Проходили уже такое.
Это не ко мне.
>> Возможно, Вы хотели подколоть на тему устойчивости?
> Нет.Да уж видно на тему чего ВЫ хотели подколоть. Что я не замечу плавно сменённой темы и начну отстаивать полнейшие глупости...
> Но данный вопрос и дальнейший текст наводит на мысль, что ты
> вообще не пытаешься думать, ты ищешь что-то знакомое в вопросах и
> выдаешь штампованные ответы.Ну а я вижу штампованные попытки заболтать надёжность микроядерной архитектуры.
Просто невероятная хуцпа какая-то. Ты же сам попытался подменить его тезис каким-то своим нелепым:> Возможно, Вы хотели подколоть на тему устойчивости? Типа, без драйвера винта сам драйвер не загрузится с винта же.
За что заслуженно получил по лбу. А теперь еще смеешь обвинять его в подмене тезиса (которой у твоего собеседника, говоря по справедливости, не было).
P.S. ты как-то обмолвился в предыдущей теме, мол, твоя миссия - проповедовать микроядерный подход, дескать, такой это важный и сложный труд. Возможно, это и так. Но тебе пора бы наконец уж понять, что со своим агрессивным невежеством все, чего ты добьешься - это только насмешек в свою сторону.
> Ты же сам попытался подменить его тезис каким-то своим нелепым...Да, спасибо, перечитал - речь была не о падении, а о произвольном коде в этих дровах.
Тогда ответ на вопрос: "и чем вам помогло отдельное адресное пространство и отсутствие рутовых привилегий?":
Кардинальным понижением вероятности получения рутовых привилегий при всех прочих равных (качестве о объёме системного кода), т.к.:
* объём кода и количество драйверов-сервисов, которые могут к этому привести, понижается на порядок.
* произвольный код в сервисе клавы и монитора - практически вообще не проблема, если система админится по сети. Что введёт "клава" или покажет "моник" эдакого для получения проблем с рутовой безопасностью?
* эксплуатация уязвимости в драйвере винта (не ФС, а именно винта) требует ещё некоторых условий и правильных действий, чтобы изменить нужное на нужной ФС и при этом не слишком удивить сервис файловой системы.> P.S. ты как-то обмолвился в предыдущей теме, мол, твоя миссия - проповедовать
> микроядерный подход, дескать, такой это важный и сложный труд.Думаю да, это нужное дело.
> Но тебе пора бы наконец уж понять, что со своим агрессивным невежеством
Невежество - отстутствие некоторых знаний.
Агрессивное невежество - видимо, отстаивание права не знать, но выступать на определённые темы.
Ну и чего же я здесь по теме не знал? (или заявлял что нечто нужное якобы неважно)
Агрессивность да, имела место, неправильно прочёл посыл человека.
Ну это отдельный вопрос.
Для полноты ответа к "произвольный код в сервисе клавы и монитора - практически вообще не проблема, если система админится по сети"
Если это десктоп система - то да, перехват клавы - это фактически сдача системы.
> Скажу даже больше: современные процессорные прерывания уже давно ничего не прерывают.
> Они записывают байт в оперативную память, показывающий, что прерывание пришло.Вас правда не затруднит дать ссылочку на спецификацию, подтверждающую такое?
https://lwn.net/Articles/44139/Если ты ещё не в курсе, то все (большинство) устройств современного компьютера считаются устройствами PCI.
И как это относится к процесорным прерываниям, которые якобы ничего не прерывают? Это лишь способ уменьшить количество необходимых векторов для прерываний и обойтись от собственно вызова прерывания устройством.
Терминологией владеешь? Очевидно что нет.Читать умные книжки не понимая отдельных слов не получится, детка.
> Вас правда не затруднит дать ссылочку на спецификацию, подтверждающую такое?Еще в архитектуре масадосовых драйверов, которые давно и надежно похоронены, были две точки входа. Стратегия и Прерывание. Так вот, Прерывание занималось только тем что ставило реквест к драйверу в очередь реквестов. Обработкой очереди реквестов занималась Стратегия.
Так что "Прерывание" фактически что тогда, что сейчас ничего не делало и не делает, кроме как чота умное записывает в память и отпускает процесс.
Другое дело что масадос была системой однозадачной, поэтому на одной из функций как правило стояла заглушка (а порой и на обеих). Но современные драйвера идеологически устроены абсолютно так-же.
Это впрочем не отменяет того факта что прерывания таки возникают. Но обработка их выполняется вне прерывания.
То, что ты описал, делали в древнюю эпоху. Драйвер должен был выполнить минимальный объём необходимых действий (напр. драйвер клавиатуры извлекал всё из буфера клавиатуры в свой личный буфер), а основную обработку откладывали на потом (драйвер клавиатуры преобразовывал коды, переключал раскладки, уведомлял об этом ОС и т.п.).В те давние времена (PIC, APIC, IOAPIC) прерывание приводило к переключению контекста и сбросу кэша. В погоне за скоростью накладные расходы на вызов прерываний сочли чрезмерными. Сейчас, как уже написал, аппаратура не прерывает выполнения программы и ОС обрабатывает прерывания когда задача "Диспетчер прерываний" начнёт выполнение.
Диспетчер прерываний преобразует каждое прерывание в событие (SendMessage) для драйвера (каждый драйвер - это отдельная задача), а когда драйвер получит управление, он столь же рутинно будет обрабатывать события.
> прерывания таки возникают
Прерывания бывают разные видов и не все виды прерывают выполнение текущей программы. 50 лет назад термин "прерывание" казался удачным, сейчас он стал таким же рудиментом, как и напр. "чайник" ("чай") или "стать" (собственное значение утрачено, употребляется лишь в одной фразе - "с какой стати?").
Давно не приходилось читать такого отборного бреда. Пишите есчо.
Давно не приходилось читать такого отборного бреда. Пишите eсчo.
Ну, ок - дпайвер клавы и диска вне ядра и работают с правами уборщици, что мешает им сделать приписки к вводу, или отдать системе подправленный бинарник считанный диска?А наверно окно с подтверждением действий в случайном месте экрана, чтобы драйвер мыши не знал куда тыкать, если вдруг и он с врагами.
Если у тебя есть доступ к диску и возможность подписать любой драйвер валидным сертификатом...Ах да, это скучно. Понимаю, понимаю. Нужно с извращениями: заменить драйвер диска (который знать не знает ни про какие FATы) и научиться подменять данные, имея столь скудную информацию. Линукс-вэйно.
Ок, давным давно придумали яву, в ней нет ошибок разыменовывания указателей и прямой работы с памятью, это безопасно говорили они, пусть и чутка медленнее, и вот в списке новостей апач-хрень с рутовым доступом на яве.Сколько новостей было о взломе центров сертификации, сколько раз находили ключи в прошивках.
На любую хитрую жопу найдется болт с резьбой. Если бы был способ надежно отделить требуемые инструкции от вредоносных, он бы уже использовался, но его просто нет. Поэтому нет никакого смысла пихать в ядро всякую хрень, которая ничего не гарантирует на 100%, кроме замедления работы и усложнения траблшутинга овер9000.
Считаешь иначе, блокнот тебе в помощь - напиши, а мы посмотрим.
> Ну предположим, что есть микроядро и драйвера в отдельном пространстве. Такие как
> драйвера клавиатуры, монитора и жестких дисков. Находится уязвимость в любом из
> них, позволяющая выполнить произвольный код. Внимание, вопрос: "и чем вам помогло
> отдельное адресное пространство и отсутствие рутовых привилегий?"Тем, что рут доступ остался только у рута.
А сбойные сервисы можно обновить и перегрузить.
Ты вообще понимаешь, о чем говоришь?
Что такое "рут" в твоем понимании? Что такое "сбойный"?
Как ты поймешь, что твой дырявый драйвер клавиатуры в твоем микроядре поимел зловред? Ну выполнит он втихаря свой код, считает нажатия клавиш и отправит их куда-нибудь. Сбоя-то нет, клавиатура вроде бы как работает, драйвер тоже не упал и дальше себе работает. Микроядерная архитектура не поможет тебе вообще никак.
> Продолжим тему вынесения драйверов на пользовательский уровень в отдельное адресное пространство?Ну плохо текущее состояние, да. Но трудов в Линукс вложено много, конкурентам не догнать.
Наука здесь в том, что таки не надо делать монолиты специально (плевок в сторону известного ...d).
> Ну плохо текущее состояние, да. Но трудов в Линукс вложено много, конкурентам
> не догнать.Какие ещё конкуренты?
Речь о будущем развитии самого Линукса. Куда ему плыть.
> состоянием гонки (race condition)О, уже прогресс!
Так, глядишь, и забудется новояз как страшный сон.
Не прогресс, а развитие.
Почему не указываете, кто уязвимость нашел?!
Написано же: программа syzkaller.
Dan Williams молодец. Без сизколлера нашел проблему.
Не ты вот и бесишься?
Опять они.
ты новости не смотришь? весь мир на ушах!ЦРУ (CIA) ))))
Ага! Русский хакер detected!
Скажите пожалуйста, а ответственные за ядро майнтейнеры сами этим syzkaller своё ядро протестировать не могут, прежде чем релизить?
Некоторые из них даже компилятором не проходятся по тому, что коммитят. Недавно Линус по этому поводу разнос устраивал.
Там суть разноса была другой. Пока чуваки вносили изменение в свой модуль, Торвальдс изменил ядро. Разумеется что оно не скомпилилось. Торвальдс по традиции поклал всех трёхэтажным и обвинил во всём других.
> Пока чуваки вносили изменение в свой модуль, Торвальдс изменил ядро."...причём вручную" (ц)
fuzzing дело такое. Сегодня что-то нашел, завтра не нашел.
Фаззинг похож на майнинг биткойнов. Только еще из краша надо эксплойт накрутить.
Вы ещё предложите им заняться QA/QC - в вас же сразу ссаные тряпки полетят.Это же Лялиx - тут каждый должен быть программистом и ковырять систему для улучшений работы.
// b.
> Это же Лялиx - тут каждый должен быть программистом и ковырять систему
> для улучшений работы.вот что должно писаться большим красным шрифтом, перед установкой каждого дистрибутива линукс, и еще надпись "мы не несем ответственности за потраченные вами время, нервы и рассудок,а так же не несем ответственности за порчу ваших данных и железа"
>> Это же Лялиx - тут каждый должен быть программистом и ковырять систему
>> для улучшений работы.
> вот что должно писаться большим красным шрифтом, перед установкой каждого дистрибутива
> линукс, и еще надпись "мы не несем ответственности за потраченные вами
> время, нервы и рассудок,а так же не несем ответственности за порчу
> ваших данных и железа"Ну в принципе такое написано, впрочем как и у тех кто за деньги, с лимитами ответственности :)
> вот что должно писаться большим красным шрифтом, перед установкой каждого дистрибутива линукс, и еще надпись "мы не несем ответственности за потраченные вами время, нервы и рассудок,а так же не несем ответственности за порчу ваших данных и железа"Так и написано: никакой ответственности никто и не несёт.
А теперь сделаем финт ушами, и добавим 100500 "а вот Вы как пользователь должны", и получится EULA! :)
> вот что должно писаться большим красным шрифтом, перед установкой каждого дистрибутива
> линукс, и еще надпись "мы не несем ответственности за потраченные вами
> время, нервы и рассудок,а так же не несем ответственности за порчу
> ваших данных и железа"Угадай, откуда:
> We collect your first and last name, email address, postal address, phone number, and other similar contact data
> We collect data about your interests and favorites
> We collect data about your contacts and relationships
> We collect content of your files and communications
юнити и/или гном 3?
В более мелких проектах код не принимают без тестов. Тесты должны писать те люди, кто пишет патч/модуль/новые функции и т.п. Поскольку ядро изначально считается вещью архисложной, этап тестирования принимается на веру. Мейнтейнер же должен смотреть код и ревьювить его, иногда писать патчи к патчам (если захочет).И чтобы писать тесты под ядро без имения соответствующей железки под рукой, нужно написать фреймворк умеющий в "Mock object" или его подобие. Например, https://lwn.net/Articles/558106/
Ядро - это важный модуль, но ни большим, ни сложным он не является.Но если включить в состав ядра все драйвера и системные библиотеки, то можно искусственно увеличить как размер, так и сложность, особенно сильно возрастает сложность совместной разработки, т.к. при разработке модуля нужно учитывать что другие модули (вкл. ядро) могут измениться непредсказуемым образом.
Для снижения сложности обычно вводят понятие "внутренний API" - набор функций, которые будут поддерживаться неизменными и об изменении которых будет сообщаться сильно заблаговременно. Но в Линукс такой практики нет.
> В более мелких проектах код не принимают без тестов. Тесты должны писать
> те люди, кто пишет патч/модуль/новые функции и т.п. Поскольку ядро изначально
> считается вещью архисложной, этап тестирования принимается на веру. Мейнтейнер же должен
> смотреть код и ревьювить его, иногда писать патчи к патчам (если
> захочет).
> И чтобы писать тесты под ядро без имения соответствующей железки под рукой,
> нужно написать фреймворк умеющий в "Mock object" или его подобие.Будем надеяться, что когда-то до мейнтейнеров дойдёт, что тесты - это не "just for fun", а суровая необходимость.
Самое смешно, что если кто-то сядет и напишет на нормальном языке недырявую ОСь, которая будет даже в три раза медленнее Линукса, её будут использовать. Хотя penalty у нормальных языков намного меньше. Я думаю, скоро это уже случится и все забудут линукс как страшный сон.
_Самое смешно, что если кто-то сядет и напишет на нормальном языке недырявую ОСь,_Ахахаха, прекратите! Сделали мой день.
> Самое смешно, что если кто-то сядет и напишет на нормальном языке недырявую
> ОСь, которая будет даже в три раза медленнее Линукса, её будут
> использовать. Хотя penalty у нормальных языков намного меньше. Я думаю, скоро
> это уже случится и все забудут линукс как страшный сон.OS Mirage. Чё-то никто не забыл, да.
Интересная штука, версия 2.0 даже рвёт линукс по скорости :)media.taricorp.net/performance-evaluation-unikernels.pdf
Скоро кровавый ынтырпрайз обратит на неё свой кровавый взор. Линуксокапец и Виндекапец близится.
> Интересная штука, версия 2.0 даже рвёт линукс по скорости :)Далеко не всегда. По Вашей ссылке рвёт только для DNS-запросов, а вот в случае HTTP просаживается нехило. Они там обнаружили существенные баги в HTTP-демоне MirageOS, так что скоро, наверное, поправят.
Вообще, мираж пока сыроват. Его пакеты в opam при определённом стечении обстоятельств имеют тенденцию не собираться, а многие - не работать, как надо. Один только модуль DNS-запросов, который не умеет правильно реагировать на EAGAIN чего стоит.
Безусловно, возможности масштабируемости, заложенные в мираж - потрясающи, но в энтерпрайз пойдёт оно не скоро. Ещё пару-тройку лет ей надо на развитие.
> media.taricorp.net/performance-evaluation-unikernels.pdf
> Скоро кровавый ынтырпрайз обратит на неё свой кровавый взор. Линуксокапец и Виндекапец
> близится.Линуксокапец вряд ли нагрянет. GNU/Linux был и останется наиболее удобной системой для профессиональных хакеров и программистов. Мираж со своей идеей unikernel позволит организовывать хорошо масштабирующиеся сервисы, но не подойдёт в качестве ОС общего назначения.
> Вообще, мираж пока сыроват.Если я правильно понимаю, то Мираж с гипервизором - это VM/CMS. Но это принципиально не UNIX система. И даже не отдалённо UNIX-подобная, как Windows NT/BeOS. Хотя и пригодная для очень условного "десктопа".
>> Вообще, мираж пока сыроват.
> Если я правильно понимаю, то Мираж с гипервизором - это VM/CMS. Но
> это принципиально не UNIX система. И даже не отдалённо UNIX-подобная, как
> Windows NT/BeOS. Хотя и пригодная для очень условного "десктопа".Вообще да, может под гипервизором оно нормально работает. Я же тестировал это дело в repl под gnu/linux, используя mirage-dns. Но. Они же заявили поддержку сборки под юниксами, и оно даже собралось. Вот только не пашет.
Для десктопа оно, кгхм... не знаю, как может быть пригодно. Это именно что гипервизор, который запускает программку на ocaml. Разве что я под свою основную систему xen подложу... Но зачем оно мне могло бы понадобиться, ума не приложу.
> Для десктопа оно, кгхм... не знаю, как может быть пригодно.Ну VM/CMS - это ОС общего назначения. Но очень специфическая и крутая - там виртуальная машина выдаётся на каждый чих. В UNIX - программа запускается, а в VM/370 - делается виртуальная машина, в которой запускается программа.
Т.е. в перспективе, возможно, Mirage может работать под гипервизором, запускать себя же в соседней виртуальной машине для вызова редактора и т.д. Но я совершенно не уверен в том, что там есть на это подходящие средства. Что даже обдуманы подходящие взаимодействия, протоколы.
>её будут использовать.Не будут, ибо религия. Увы.
> сядет и напишет на нормальном языке недырявую ОСь
> лютый жабистЭто на жабке то?
Нет.
Это на каком же нормальном языке надо писать, чтобы гарантированно не было race conditions?
Зато вон в DOS никакие рейсов нет, несмотря на сишечку. Все валим на DOS?
> Зато вон в DOS никакие рейсов нет, несмотря на сишечку.Чего? Там даже реентаребельности во многих местах не было, а вы про race condition.
> Чего? Там даже реентаребельности во многих местах не было, а вы про race condition."Во многих" ? Да Бог с вами. Учитывая то что в DOS проще пересчитать места где она была (пальцев на двух руках хватило бы точно), чем где ее не было, можно с уверенностью считать что ее не было во всех местах. Весь ввод-вывод был нереентерабелен в принципе (но кажется с 4 версии туда приколотили специальный недокументированный коллбэк, в обработчике которого можно было недокументированным образом поменять недокументированный системный контекст, и получить реентерабельность, правда за реентерабельностью BIOS следить была отдельная забота). Я уверенно могу назвать только две функции реентерабельных, запрос версии, и получение List Of Lists.
> Самое смешно,
> что если кто-то сядет и напишет на нормальном языке недырявую ОСь,
> её будут использовать.Самое смешно, что те, кто использовал маздай, будут его и дальше использовать.
Частота обнаружения уязвимостей в ядре со временем увеличивается? Есть статистика?
мне кажется, или кто то прочитал документы по атаке от "викиликса" ?
Хот-фикс выглядит как-то так
rm -f /lib/modules/*/kernel/drivers/tty/n_hdlc.ko
(за исключением реально эксплуатирующих HDLC-based)
after
#depmod -a
Хех, это я смогу через пару дней рута у себя в андроиде заиметь? Отличненько, ждем.
> Хех, это я смогу через пару дней рута у себя в андроиде
> заиметь? Отличненько, ждем.Не беспокойся, твой вендор быстренько "поправит" предварительно залив ещё гиг бэкдоров и "прослушек".
при использовании временного решения как в статье какие сестевые протоколы функции могут отвалиться? или какие основные утилиты этот протокол используют?
При ущербной архитектуре моноядер этот зоопарк дыр неизбежен...