The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект Openwall подготовил модуль для защиты от эксплуатации уязвимостей в ядре Linux

30.01.2018 09:11

Проект Openwall, известный своими инициативами по обеспечению безопасности, представил первый экспериментальный выпуск механизма LKRG (Linux Kernel Runtime Guard), предназначенного для контроля целостности ядра Linux и обнаружения попыток эксплуатации уязвимостей в ядре. Проект находится на стадии тестирования экспериментального прототипа. Лицензия на код модуля пока не выбрана, рассматривается GPLv2. Для финансирования разработки в будущем не исключается выпуск расширенной платной версии LKRG Pro.

LKRG оформлен в виде загружаемого модуля ядра, который пытается выявлять несанкционированное внесение изменений в работающее ядро (проверка целостности) или изменение полномочий пользовательских процессов (определение применения эксплоитов). Проверка целостности выполняется на основе сравнения хэшей, вычисляемых для наиболее важных областей памяти и структур данных ядра (IDT (Interrupt Descriptor Table), MSR, таблицы системных вызовов, все процедуры и функции, обработчики прерываний, списки загруженных модулей, содержимое секции .text модулей, атрибуты процессов и т.п.). Процедура проверки активируется как периодически по таймеру, так и при наступлении различных событий в ядре (например, при выполнении системных вызовов setuid, setreuid, fork, exit, execve, do_init_module и т.п.).

Определение возможного применения эксплоитов и блокирование атак производится на стадии до предоставления ядром доступа к ресурсам (например, до открытия файла), но после получения процессом несанкционированных полномочий (например, смена UID). При выявлении несанкционированного поведения процессов выполняется их принудительное завершение, чего достаточно для блокирования многих эксплоитов. Так как проект находится на стадии разработки, а оптимизации пока не проводились, накладные расходы от работы модуля составляют примерно 6.5%, но в будущем планируется существенно снизить данный показатель.

Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux, так и для противостояния эксплоитам для ещё неизвестных уязвимостей, если в них не применяется специальных мер для обхода LKRG. При тестировании LKRG успешно справился с определением попыток эксплуатации уязвимостей CVE-2014-9322 (BadIRET), CVE-2017-5123 (отсутствие проверки access_ok() в waitid()) и CVE-2017-6074 (use-after-free в DCCP), но не подходит для определения таких проблем, как CVE-2016-5195 (Dirty COW), поражающих компоненты пространства пользователя через ядро.

Авторы не исключают наличия ошибок в коде LKRG и возможных ложных срабатываний, поэтому пользователям предлагается сопоставить риски от возможных ошибок в LKRG c пользой от предлагаемого метода защиты. Из положительных свойств LKRG отмечается то, что механизм защиты выполнен в виде загружаемого модуля, а не патча к ядру, что позволяет использовать его со штатными ядрами дистрибутивов. В частности, модуль опробован с ядром RHEL7, OpenVZ/Virtuozzo 7 и Ubuntu 16.04. В дальнейшем возможно будет организован процесс формирования бинарных сборок для популярных дистрибутивов.

В будущем также ожидается поддержка отслеживания выхода за пределы изолированных контейнеров (смена namespace) и полноценные средства для блокирования атак - в текущей версии сведения о нарушениях целостности выводятся в виде информационных уведомлений, записываемых в лог ядра. Отдельно развивается расширенный вариант модуля, в котором предоставлены дополнительные опции для защиты процессов, файлов и логов (например, защищённый лог не может быть изменён и удалён, даже пользователем root, а только дополнен).

  1. Главная ссылка к новости (http://www.openwall.com/lists/...)
  2. OpenNews: Обновление сборки Openwall GNU/*/Linux 3.1-stable
  3. OpenNews: Проект Openwall представил web-интерфейс blists и новый список рассылки kernel-hardening
  4. OpenNews: Обновлены патчи ядра Linux от Openwall и подготовлены установочные образы дистрибутива Owl
  5. OpenNews: Проект по продвижению в ядро Linux новых технологий активной защиты
  6. OpenNews: Линус Торвальдс раскритиковал ограничительные меры по усилению защиты ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47989-openwall
Ключевые слова: openwall, kernel, lkrg
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, AnPoz (ok), 10:32, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучшая защита это отсутствие возможности.
     
     
  • 2.2, наноним (?), 10:35, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +40 +/
    нет компьютера - нет уязвимостей!
     
     
  • 3.51, Шумер (?), 10:44, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    "Нам эти ваши интернеты на... не нужны!" (с)
     
     
  • 4.66, Аноним (-), 17:34, 02/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Увы, иранцам это не помогло, так что отсутствие компьютеров таки безопаснее.
     
  • 3.60, 123 (??), 18:27, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    RMS одобряет. Он таким образом решил для себя проблему с телефонами.
     
     
  • 4.71, DmA (??), 15:15, 31/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    RMS телефоном пользуется, но только не сотовым, а если приходится пользоваться сотовым, то он его включает когда очень нужно.
     

  • 1.6, Аноним (-), 11:32, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG

    Ошибки не исключены на любой стадии.

     
     
  • 2.17, Andrey Mitrofanov (?), 13:33, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG
    > Ошибки не исключены на любой стадии.

    На другой стадии они из будут исключать -- и ошибаться в этом.

     
     
  • 3.27, solardiz (ok), 15:49, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Не будем исключать. Это ошибка при составлении новости на OpenNet (но всё равно большое спасибо модераторам что вникли в суть проекта и опубликовали здесь новость). В исходном английском тексте это два разных абзаца - один о том что ошибки и в том числе уязвимости в самом LKRG возможны (и это надо учитывать при принятии решения о его (не-)использовании в конкретном случае) и другой о том что проект на ранней стадии и мы ожидаем ложные срабатывания (из-за чего LKRG пока не принимает жестких мер при обнаружении нарушений).
     

  • 1.7, Аноним (-), 11:51, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
     
     
  • 2.8, Аноним (-), 11:52, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотя модулем такое сделать скорее всего не получится.
     
     
  • 3.9, Аноним (-), 12:21, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
    > Хотя модулем такое сделать скорее всего не получится.

    Ви таки хотите поломать нашу любимую машину Тьюринга? И добавить туда блекджека и ...

     

  • 1.10, Аноним (-), 12:31, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://openwall.info/wiki/p_lkrg/Protected_Features

    приятных им глюков с kretprobe. Удачи преодолеть ситуацию когда k[ret]probe может быть не вызван.

     
  • 1.13, X4asd (ok), 13:07, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    хренью занимаются..

    придумали какого-то касперского для Linux.

     
     
  • 2.30, Michael Shigorin jolla (?), 16:41, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > хренью занимаются..

    Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(

    но вот что мешало помолчать или спросить?..

     
     
  • 3.40, pavlinux (ok), 23:51, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> хренью занимаются..
    > Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(
    > но вот что мешало помолчать или спросить?..

    Всё нормально, мы для таких и работаем.


     
  • 3.43, Аноним (-), 00:04, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    недостаток очевиден:

    медной проволокой прикрутили костылище..

    вполне себе обыкновенный антиметирн под названием "Katamari"..

    вот так стало тебе легче понять фразу "занимаются хренью"?

     
     
  • 4.44, Аноним (-), 00:04, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    антипаттерн*
     

  • 1.14, Аноним (-), 13:07, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > для противостояния эксплоитам для ещё неизвестных уязвимостей, если в них не применяется специальных мер для обхода LKRG

    Ну то есть всё как обычно. Если эта штука станет достаточно распространена, её быстро научатся обходить, и даже авторы этого не отрицают.

     
  • 1.16, Аноним (-), 13:32, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Openwall
    > защиты от эксплуатации уязвимостей в ядре Linux

    Неудачное название для такого класса проектов, — "открытая стена".

     
     
  • 2.19, Andrey Mitrofanov (?), 13:44, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> Openwall
    >> защиты от эксплуатации уязвимостей в ядре Linux
    > Неудачное название для такого класса проектов, — "открытая стена".

    Окна(tm)(R)(sm)  --  лучше?

     
     
  • 3.23, pavlinux (ok), 15:18, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> Openwall
    >>> защиты от эксплуатации уязвимостей в ядре Linux
    >> Неудачное название для такого класса проектов, — "открытая стена".
    > Окна(tm)(R)(sm)  --  лучше?

    Солнышко, Яблоко, Дурдом Ромашка, Конц. лагерь Огонёк. ...

     
  • 2.26, solardiz (ok), 15:40, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> Openwall
    >> защиты от эксплуатации уязвимостей в ядре Linux
    > Неудачное название для такого класса проектов, — "открытая стена".

    По-моему, наоборот очень удачное. У нас motto - "bringing security into open environments" - то есть мы обеспечиваем безопасность в открытых системах, почти без снижения их доступности для пользователей. На момент выбора названия (1999 год), была тенденция у веб-хостеров отнимать у пользователей доступ к Unix shell (при этом реально безопасность, может быть, и не повышая - всё равно давался FTP-доступ для размещения едва ограниченных PHP-скриптов). Мы так не хотели, поэтому занялись созданием такого дистрибутива где с приемлемым уровнем риска можно давать доступ в shell. Тенденция с тех пор переломилась, но смысл названия остался, он по-прежнему актуален, и к нему еще можно добавить то что мы не преувеличиваем уровень безопасности наших разработок - что особенно хорошо видно как раз в данном анонсе LKRG.

     

  • 1.20, Нанобот (ok), 14:30, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
     
     
  • 2.25, solardiz (ok), 15:27, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)

    Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG называем integrity checking, и не включает то что мы называем exploit detection.

    А чем именно "жалкое", кроме как датой появления?

     
     
  • 3.31, Michael Shigorin jolla (?), 16:47, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А чем именно "жалкое", кроме как датой появления?

    это именно что жалкий виндовбросчик, не стоит внимания

     
  • 3.42, pavlinux (ok), 23:54, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
    > Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG
    > называем integrity checking, и не включает то что мы называем exploit
    > detection.
    > А чем именно "жалкое", кроме как датой появления?

    Нельзя защищать то (от того), чего еще нет. :)

     

  • 1.21, Ананас (?), 14:52, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Лет 10-12 назад проблема достойно решалась использованием LIDS.
    Теперь вариант с LKRG...
    Все вращается по кругу.
     
     
  • 2.24, solardiz (ok), 15:19, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    По-моему, общее с LIDS здесь только то, что в новости в последней фразе последнего абзаца - "Отдельно развивается расширенный вариант модуля, в котором предоставлены дополнительные опции для защиты процессов, файлов и логов" - что в переписке с Адамом (автор LKRG) я называю BSD securelevel on steroids, и что мы сами в нынешний анонс даже не включали (кроме как через ссылку на wiki, где это есть). Это имеет мало общего с той функциональностью, которую мы анонсировали сейчас, и будет ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем, где даже обновления ядра вовремя не ставятся (или перезагрузка в новое ядро делается не сразу), в то время как разумное применение подобия securelevel требует нетривиальной настройки и последующего внимания.
     
     
  • 3.55, ПавелС (ok), 14:28, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > предоставлены дополнительные опции для защиты процессов, файлов и логов" - что
    > в переписке с Адамом (автор LKRG) я называю BSD securelevel on
    > steroids, и что мы сами в нынешний анонс даже не включали
    > (кроме как через ссылку на wiki, где это есть). Это имеет
    > мало общего с той функциональностью, которую мы анонсировали сейчас, и будет
    > ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас
    > основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем,
    > где даже обновления ядра вовремя не ставятся (или перезагрузка в новое
    > ядро делается не сразу), в то время как разумное применение подобия
    > securelevel требует нетривиальной настройки и последующего внимания.

    BSD securelevel  результат  тяжёлой паранойи поверьте мне. Ум рассматривал ситуацию когда в системе два рута он и хакер и решил зацепиться за отключение двух капабилитисов.

     

  • 1.34, VINRARUS (ok), 21:01, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А я сказал: "Вот и на Linux появился антивирус"!
    Шо за цензура на ресурсе?
     
     
  • 2.38, Michael Shigorin (ok), 23:09, 30/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А я сказал: "Вот и на Linux появился антивирус"!
    > Шо за цензура на ресурсе?

    Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...
    (но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту не хватает квалификации даже понять это)

     
     
  • 3.47, VINRARUS (ok), 04:20, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> А я сказал: "Вот и на Linux появился антивирус"!
    >> Шо за цензура на ресурсе?
    > Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика
    > нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...

    В чом истерика то? Обычная констатация факта. А аргументы в новости написаны: "Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux, так и для противостояния эксплоитам для ещё неизвестных уязвимостей"
    > (но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту
    > не хватает квалификации даже понять это)

    И чем принципиально отличается этот модуть от антивируса?

     
     
  • 4.53, Аноним (-), 11:19, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> чем принципиально отличается этот модуть от антивируса?

    Ну наверное тем, что как раз вирусы-то он и не ловит.

     
     
  • 5.61, VINRARUS (ok), 20:40, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >>> чем принципиально отличается этот модуть от антивируса?
    > Ну наверное тем, что как раз вирусы-то он и не ловит.

    Как будто антивирус их ловит. ;D

     

  • 1.35, worldmind (?), 21:51, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Так теперь хакеры будут сначала модифицировать этот модуль, а потом уже ядро?
     
     
  • 2.69, Аноним (-), 13:19, 04/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно только модуль.
     

  • 1.50, Аноним (-), 09:02, 31/01/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?
     
     
  • 2.54, Аноним (-), 12:15, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает
    > найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?

    Если кто-то добьётся RCE на уровне ядра, то зачем ему что-то менять, когда RCE уже получен:-)  LKRG  и нужен, чтобы RCE не случился.

     
     
  • 3.62, Аноним (-), 22:01, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то я спрашивал solar designerа.

    Имхо тут 2 варианта.
    1 проверка происходит до того, как атакующий обошёл защиту памяти. Тогда структуры неповреждены и проверка ничего не выявляет.
    2 проверка происходит после модификации памяти атакующим на уже скомпромитированной системе. Раз атакующий может модифицировать память, то он может пересчитать хеши записать их куда надо. Проверка опять ничего не выявляет.

     
     
  • 4.63, solardiz (ok), 22:45, 31/01/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Во-первых, мы сразу позиционируем 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). Может быть, это будут две ветки разработки.

     
     
  • 5.64, Аноним (-), 03:36, 01/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ясно, спасибо.
     
  • 5.67, Аноним (-), 18:41, 02/02/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Звучит очень разумно. Это не абсолютная защита, но подложить атакующим пару мин - идея хороша. Жаль что как обычно будет куском проблем в использовании и опять какие-нибудь скандалы с майнлайном выйдут. Хотя с такой защитой по другому сложно.
     

  • 1.65, Аноним (-), 14:00, 01/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А вот и антивирус, в pro версии видимо добавят сигнатуры эксплоитов ;-)
     
     
  • 2.68, Аноним (-), 04:49, 03/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Прежде, чем добавлять сигнатуры в Pro версию, надо убедиться, что те эксплойты обходят Free версию :-)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру