The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "
Отправлено Аноним, 08-Июн-22 19:00 
> Вообще не понятно, почему что-то вообще должно выполняться на уровне загрузчика?

Это отличный вопрос к знатокам GRUB2. Примерно за тем же зачем ему поддержка PNG, BMP, TGA и прочего. GRUB2 по своим размерам тянет на небольшую ОС.

> Как можно лечить проблему (загрузка вредоносного кода на уровне ядра системы) и создать новую проблему -- загрузка вредоносного кода на уровне загрузчика (и, кстати, UEFI, при определённых обстоятельствах)

Потому что вместо того чтобы заниматься внедрением цифровой подписи кода в Linux истерически применялись попытки обойти это, теми же самыми костылями с shim, лишь бы не внедрять.

Изначальная проблема, которую решает Secure Boot - это проблема специфических вирусов, которые портят загрузчик ОС. Их логика целиком построена на социальной инженерии, дескать, обманутый пользователь запустит код в привилегированном режиме и тем самым испортит себе загрузчик. Аналогично это усложняет написание руткитов, потому что теперь всем этим вирусам нужно обзавестись цифровой подписью и пройти через 7 кругов бюрократического ада, доказывая, что ты не верблюд. По итогам этих изменений в Windows стало очень трудно писать такие вирусы и народ переключился на шифровальщики, работающие целиком в пространстве пользователя, но это уже другая история.

Под Linux таких вирусов нет, потому что там нет пользователя, который попадётся на такие уловки. Нету спроса - нету предложения. Когда ОС пользуется больше 1.3 миллиарда человек, то даже 5% умственно отсталых пользователей (а их больше), жамкающих разрешить себе всё - это, на минуточку, 65 миллионов! Теперь давайте представим себе ботнет таких размеров и поймём почему принимаются те или иные решения.

Логика цифровых подписей начинается с UEFI Secure Boot (не грузить что попало, если пользователь явно не разрешил), продолжается ядром ОС, которое проверяет цифровые подписи всех своих модулей. Пользовательская подсистема проверяет сертификаты всех исполняемых файлов и жалуется на их отсутствие. Файрвол, который определяет зоны, откуда взялся файл и файловая система проставляет любому файлу блокирующие атрибуты, чтобы нельзя было автоматом после скачивания файла из интернета его запустить без дополнительных проверок (хэширование и сличение с базой известных вирусов, проверка цифровых подписей и прочее). Даже текстовые сценарии должны быть подписаны, а если они пытаются обращаться напрямую к объектам ядра и драйверов, то вне зависимости от наличия сертификатов, такая активность считается вредоносной.

Это всё потому что пользователи по природе своей не очень разбираются в ИТ и не обязаны это делать, чтобы лайкать котиков в социальных сетях.

Теперь давайте посмотрим что сделано в Linux. Есть костыль shim, чтобы не подписывать ни ядро, ни драйверы. Подсистема цифровых подписей в ядре, не та новая, которую дописывал MS, портируя свой WHQL, а оригинальная, полагается на хранилища сертификации на файловой в системе, что глупо. И вот если это всё включить,.. но оно выключено по-умолчанию. Про подпись кода и скриптов я вообще ничего не буду говорить, это слишком на стороне DE, а там все озабочены Wayland-танцами уже последние 8 лет. И всё это можно было бы довести до ума, учитывая, что в ядре-то всё есть... Дистрибутивы не пользуются, впрочем подобное много лет назад наблюдалось вокруг cgroups и систем мандатного контроля.

Причем в каждом сообществе найдутся 10 баранов-меинтейнеров, которые дальше make; make install одного пакетика задачи не видели, которые сбегутся и начнут рассуждать, как же это всё никому не нужно. Если же хотя бы 5 из них начнут переписку до приёма прописанных таблеток, то окажется, что это мало того что не нужно, так еще и вредно, потому что злобный MS замышляет козни против Linux, вводя для СВОИХ пользователей PKI на уровне выполнения кода.

Техническая сложность в Linux всего одна: монолитность. В Windows обновления драйверов и целой кучи подсистем идёт отдельно от основного ядра, потому что большая часть драйверов, строго говоря в юзерспейсе. У WinNT действительно маленький Ring 0. Динамическая же часть ядра живёт отдельно. Те драйверы, цифровые подписи и проверки выполняются совершенно другой подсистемой, никак не подпадающей под UEFI и вопросы безопасной ЗАГРУЗКИ. В Linux всё монолитно, поэтому каждое минорное обновление потенциально ненужного на конкретном устройстве модуля должно заменить цифровую подпись всея ядра. И вот чтобы было как в Windows они выделили маленький кусочек отдельно и вот он вам shim.

Ну и вишенка на торте - это поддержка Userspace drivers в Linux: https://www.kernel.org/doc/html/latest/driver-api/uio-howto....
Она есть, просто всё принято тащить в ядро сочиняя себе новые API и ломая старое API, которое там было. Ну и поверх нужно сделать 100500 версий одного и того же ядра на уровне дистрибутивов. Но ладно драйверы... вся сетевая подсистема должна обновляться с ядром, включая файрвол и графика.... И соответственно триггерить смену подписей. Жуткая помойка, которая накопилась из нерешенных проблем с размерами монолитной кодовой базы. Молодежь уже даже не понимает, что такие вещи как kmod и dkms это адские костыли, которые прикрывают архитектурные проблемы фиговым листочком.

> Кстати, никто не знает, почему запускаемый код называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает?

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

Ну и последнее, PKI - это не безопасность, а номенклатурные отношения доверия. PKI в этом случае отвечает на вопрос, является ли код доверенным или нет, и кто гарантирует вам это доверие. Любая безопасность строится не на концепции абсолютной защиты (её нет), а на том, что нужно как можно дольше тянуть время и как можно громче сообщать, параллельно вставляя палки в колёса атакующему коду. Бюрократическая неповоротливость PKI замечательно показала себя по вопросам усложнения жизни тем кто хочет запустить недоверенный код, вот её и используют.

P.S. Я вообще не понимаю, почему в GRUB не впилят поддержку MP3, очень не хватает слушать музло во время просмотра любимой картинки во время ожидания загрузки пункта меню. Народу явно больше зайдёт чем нормальная поддержка верификации кода на уровне ОС.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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