Проект Openwall, известный своими инициативами по обеспечению безопасности, представил (http://www.openwall.com/lists/announce/2018/01/29/1) первый экспериментальный выпуск механизма LKRG (http://www.openwall.com/lkrg/) (Linux Kernel Runtime Guard), предназначенного для контроля целостности ядра Linux и обнаружения попыток эксплуатации уязвимостей в ядре. Проект находится на стадии тестирования экспериментального прототипа. Лицензия на код модуля (https://bitbucket.org/Adam_pi3/lkrg-main) пока не выбрана, рассматривается (http://openwall.info/wiki/p_lkrg/Main) GPLv2 или GPLv3. Для финансирования разработки в будущем не исключается выпуск расширенной платной версии LKRG Pro.
LKRG оформлен в виде загружаемого модуля ядра, который пытается выявлять несанкционированное внесение изменений в работающее ядро (проверка целостности) или изменение полномочий пользовательских процессов (определение применения эксплоитов). Определение возможного применения эксплоитов и блокирование атак производится на стадии до предоставления ядром доступа к ресурсам (например, к открытию файла) после получения процессом несанкционированных полномочий.В будущем ожидается поддержка отслеживания выхода за пределы изолированных контейнеров. Также пока отсутствуют полноценные средства для блокирования атак - сведения о нарушениях целостности выводятся в виде информационных уведомлений, записываемых в лог ядра. При выявлении несанкционированного поведения процессов выполняется их принудительное завершение, чего достаточно для блокирования многих эксплоитов. Так как проект находится на стадии разработки и оптимизации пока не проводились, накладные расходы от работы модуля составляют примерно в 6.5%, но в будущем планируется существенно снизить данный показатель.
Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux, так и для противостояния эксплоитам для ещё неизвестных уязвимостей, если в них не применяется специальных мер для обхода LKRG. При тестировании LKRG успешно справился с определением попыток эксплуатации уязвимостей CVE-2014-9322 (BadIRET), CVE-2017-5123
(waitid) и CVE-2017-6074 (use-after-free в DCCP), но не подходит для определения таких проблем, как CVE-2016-5195 (Dirty COW (https://www.opennet.me/opennews/art.shtml?num=45354)), поражающих компоненты пространства пользователя через ядро.
На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG и возможных ложных срабатываний, поэтому пользователям предлагается сопоставить риски от возможных ошибок в LKRG c пользой от предлагаемого метода защиты. Из положительных свойств LKRG отмечается то, что механизм защиты выполнен в виде загружаемого модуля, а на патча к ядру, что позволяет использовать его со штатными ядрами дистрибутивов. В частности, модуль опробован с ядром RHEL7, OpenVZ/Virtuozzo 7 и Ubuntu 16.04. В дальнейшем не исключается формирования бинарных сборок для популярных дистрибутивов.
URL: http://www.openwall.com/lists/announce/2018/01/29/1
Новость: http://www.opennet.me/opennews/art.shtml?num=47989
Лучшая защита это отсутствие возможности.
нет компьютера - нет уязвимостей!
"Нам эти ваши интернеты на... не нужны!" (с)
Увы, иранцам это не помогло, так что отсутствие компьютеров таки безопаснее.
RMS одобряет. Он таким образом решил для себя проблему с телефонами.
RMS телефоном пользуется, но только не сотовым, а если приходится пользоваться сотовым, то он его включает когда очень нужно.
> На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRGОшибки не исключены на любой стадии.
>> На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG
> Ошибки не исключены на любой стадии.На другой стадии они из будут исключать -- и ошибаться в этом.
Не будем исключать. Это ошибка при составлении новости на OpenNet (но всё равно большое спасибо модераторам что вникли в суть проекта и опубликовали здесь новость). В исходном английском тексте это два разных абзаца - один о том что ошибки и в том числе уязвимости в самом LKRG возможны (и это надо учитывать при принятии решения о его (не-)использовании в конкретном случае) и другой о том что проект на ранней стадии и мы ожидаем ложные срабатывания (из-за чего LKRG пока не принимает жестких мер при обнаружении нарушений).
Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
Хотя модулем такое сделать скорее всего не получится.
> Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
> Хотя модулем такое сделать скорее всего не получится.Ви таки хотите поломать нашу любимую машину Тьюринга? И добавить туда блекджека и ...
http://openwall.info/wiki/p_lkrg/Protected_Featuresприятных им глюков с kretprobe. Удачи преодолеть ситуацию когда k[ret]probe может быть не вызван.
хренью занимаются..придумали какого-то касперского для Linux.
> хренью занимаются..Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(
но вот что мешало помолчать или спросить?..
>> хренью занимаются..
> Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(
> но вот что мешало помолчать или спросить?..Всё нормально, мы для таких и работаем.
недостаток очевиден:медной проволокой прикрутили костылище..
вполне себе обыкновенный антиметирн под названием "Katamari"..
вот так стало тебе легче понять фразу "занимаются хренью"?
антипаттерн*
> для противостояния эксплоитам для ещё неизвестных уязвимостей, если в них не применяется специальных мер для обхода LKRGНу то есть всё как обычно. Если эта штука станет достаточно распространена, её быстро научатся обходить, и даже авторы этого не отрицают.
> Openwall
> защиты от эксплуатации уязвимостей в ядре LinuxНеудачное название для такого класса проектов, — "открытая стена".
>> Openwall
>> защиты от эксплуатации уязвимостей в ядре Linux
> Неудачное название для такого класса проектов, — "открытая стена".Окна(tm)(R)(sm) -- лучше?
>>> Openwall
>>> защиты от эксплуатации уязвимостей в ядре Linux
>> Неудачное название для такого класса проектов, — "открытая стена".
> Окна(tm)(R)(sm) -- лучше?Солнышко, Яблоко, Дурдом Ромашка, Конц. лагерь Огонёк. ...
>> Openwall
>> защиты от эксплуатации уязвимостей в ядре Linux
> Неудачное название для такого класса проектов, — "открытая стена".По-моему, наоборот очень удачное. У нас motto - "bringing security into open environments" - то есть мы обеспечиваем безопасность в открытых системах, почти без снижения их доступности для пользователей. На момент выбора названия (1999 год), была тенденция у веб-хостеров отнимать у пользователей доступ к Unix shell (при этом реально безопасность, может быть, и не повышая - всё равно давался FTP-доступ для размещения едва ограниченных PHP-скриптов). Мы так не хотели, поэтому занялись созданием такого дистрибутива где с приемлемым уровнем риска можно давать доступ в shell. Тенденция с тех пор переломилась, но смысл названия остался, он по-прежнему актуален, и к нему еще можно добавить то что мы не преувеличиваем уровень безопасности наших разработок - что особенно хорошо видно как раз в данном анонсе LKRG.
жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
> жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG называем integrity checking, и не включает то что мы называем exploit detection.
А чем именно "жалкое", кроме как датой появления?
> А чем именно "жалкое", кроме как датой появления?это именно что жалкий виндовбросчик, не стоит внимания
>> жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
> Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG
> называем integrity checking, и не включает то что мы называем exploit
> detection.
> А чем именно "жалкое", кроме как датой появления?Нельзя защищать то (от того), чего еще нет. :)
Лет 10-12 назад проблема достойно решалась использованием LIDS.
Теперь вариант с LKRG...
Все вращается по кругу.
По-моему, общее с LIDS здесь только то, что в новости в последней фразе последнего абзаца - "Отдельно развивается расширенный вариант модуля, в котором предоставлены дополнительные опции для защиты процессов, файлов и логов" - что в переписке с Адамом (автор LKRG) я называю BSD securelevel on steroids, и что мы сами в нынешний анонс даже не включали (кроме как через ссылку на wiki, где это есть). Это имеет мало общего с той функциональностью, которую мы анонсировали сейчас, и будет ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем, где даже обновления ядра вовремя не ставятся (или перезагрузка в новое ядро делается не сразу), в то время как разумное применение подобия securelevel требует нетривиальной настройки и последующего внимания.
>[оверквотинг удален]
> предоставлены дополнительные опции для защиты процессов, файлов и логов" - что
> в переписке с Адамом (автор LKRG) я называю BSD securelevel on
> steroids, и что мы сами в нынешний анонс даже не включали
> (кроме как через ссылку на wiki, где это есть). Это имеет
> мало общего с той функциональностью, которую мы анонсировали сейчас, и будет
> ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас
> основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем,
> где даже обновления ядра вовремя не ставятся (или перезагрузка в новое
> ядро делается не сразу), в то время как разумное применение подобия
> securelevel требует нетривиальной настройки и последующего внимания.BSD securelevel результат тяжёлой паранойи поверьте мне. Ум рассматривал ситуацию когда в системе два рута он и хакер и решил зацепиться за отключение двух капабилитисов.
А я сказал: "Вот и на Linux появился антивирус"!
Шо за цензура на ресурсе?
> А я сказал: "Вот и на Linux появился антивирус"!
> Шо за цензура на ресурсе?Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...
(но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту не хватает квалификации даже понять это)
>> А я сказал: "Вот и на Linux появился антивирус"!
>> Шо за цензура на ресурсе?
> Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика
> нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...В чом истерика то? Обычная констатация факта. А аргументы в новости написаны: "Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux, так и для противостояния эксплоитам для ещё неизвестных уязвимостей"
> (но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту
> не хватает квалификации даже понять это)И чем принципиально отличается этот модуть от антивируса?
>> чем принципиально отличается этот модуть от антивируса?Ну наверное тем, что как раз вирусы-то он и не ловит.
>>> чем принципиально отличается этот модуть от антивируса?
> Ну наверное тем, что как раз вирусы-то он и не ловит.Как будто антивирус их ловит. ;D
Так теперь хакеры будут сначала модифицировать этот модуль, а потом уже ядро?
Достаточно только модуль.
solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?
> solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает
> найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?Если кто-то добьётся RCE на уровне ядра, то зачем ему что-то менять, когда RCE уже получен:-) LKRG и нужен, чтобы RCE не случился.
Вообще-то я спрашивал solar designerа.Имхо тут 2 варианта.
1 проверка происходит до того, как атакующий обошёл защиту памяти. Тогда структуры неповреждены и проверка ничего не выявляет.
2 проверка происходит после модификации памяти атакующим на уже скомпромитированной системе. Раз атакующий может модифицировать память, то он может пересчитать хеши записать их куда надо. Проверка опять ничего не выявляет.
Во-первых, мы сразу позиционируем LKRG как bypassable by design и как предоставляющий лишь спорную security through diversity. Именно об этом говорится в анонсе по ссылке из новости здесь.Во-вторых, с другой стороны, не каждая уязвимость в ядре и не каждый ее exploit приводит именно/сразу к RCE. Возможны ситуации, когда атакующему доступна попытка записи от имени и в адресное пространство ядра с какими-либо ограничениями или доступны лишь отдельные bit flips (как в случае с Rowhammer). В этих случаях у LKRG есть шанс (но не гарантия) распознать проблему до того как атакующий выполнит следующие шаги атаки.
В-третьих, из-за LKRG exploit'ы могут усложняться, а их надежность снижаться. В приведенном примере с пересчетом хешей, потребуется сначала найти их и ключ для SipHash (который генерируется случайно при загрузке модуля). Думаю, сейчас это, уже имея RCE, сделать не сложно - мы пока не пытались скрыть расположение этих переменных. Также, думаю есть более простые и надежные способы обхода текущей версии LKRG. Мы пока не решили будем ли развивать проект в сторону борьбы с обходами (чтобы повысить сложность и снизить надежность exploit'ов всё равно обходящих LKRG) или же, наоборот, решим еще более ограничиться security through diversity (позволяя любому желающему легко и надежно обходить LKRG, но зато упростив и сделав более быстрым и надежным код LKRG). Может быть, это будут две ветки разработки.
Ясно, спасибо.
Звучит очень разумно. Это не абсолютная защита, но подложить атакующим пару мин - идея хороша. Жаль что как обычно будет куском проблем в использовании и опять какие-нибудь скандалы с майнлайном выйдут. Хотя с такой защитой по другому сложно.
А вот и антивирус, в pro версии видимо добавят сигнатуры эксплоитов ;-)
Прежде, чем добавлять сигнатуры в Pro версию, надо убедиться, что те эксплойты обходят Free версию :-)