Введение
Прошивки современных материнских плат компьютера работают по спецификации UEFI, и с 2013 года поддерживают технологию проверки подлинности загружаемых программ и драйверов Secure Boot, призванную защитить компьютер от буткитов. Secure Boot блокирует выполнение неподписанного или недоверенного программного кода: .efi-файлов программ и загрузчиков операционных систем, прошивок дополнительного оборудования (OPROM видеокарт, сетевых адаптеров).Secure Boot можно отключить на любой магазинной материнской плате, но обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.
Большинство материнских плат поставляется только с ключами Microsoft в качестве доверенных, из-за чего создатели загрузочного ПО вынуждены обращаться в Microsoft за подписью загрузчиков, проходить процедуру аудита, и обосновывать необходимость глобальной подписи их файла, если они хотят, чтобы диск или флешка запускались без необходимости отключения Secure Boot или добавления их ключа вручную на каждом компьютере.
Подписывать загрузчики у Microsoft приходится разработчикам дистрибутивов Linux, гипервизоров, загрузочных дисков антивирусов и программ для восстановления компьютера.
Мне хотелось сделать загрузочную флешку с различным ПО для восстановления компьютера, которая бы грузилась без отключения Secure Boot. Посмотрим, как это можно реализовать.
Подписанные загрузчики загрузчиков
Итак, чтобы загрузить Linux при включенном Secure Boot, нужен подписанный загрузчик. Microsoft запретила подписывать ПО, лицензированное под GPLv3, из-за запрета тивоизации правилами лицензии, поэтому GRUB подписать не получится.В ответ на это, Linux Foundation выпустили PreLoader, а Мэтью Гарретт написал shim — маленькие начальные загрузчики, проверяющие подпись или хеш следующего загружаемого файла. PreLoader и shim не используют сертификаты UEFI db, а содержат базу разрешенных хешей (PreLoader) или сертификатов (shim) внутри себя.
Обе программы, помимо автоматической загрузки доверенных файлов, позволяют загружать и любые ранее недоверенные файлы в режиме Secure Boot, но требуют физического присутствия пользователя: при первом запуске необходимо выбрать добавляемый сертификат или файл для хеширования в графическом интерфейсе, после чего данные заносятся в специальную переменную NVRAM материнской платы, которая недоступна для изменения из загруженной операционной системы. Файлы становятся доверенными только для этих пред-загрузчиков, а не для Secure Boot вообще, и запустить их без PreLoader/shim всё равно не получится.
Действия, необходимые при первом запуске недоверенной программы через shim.
Все современные популярные дистрибутивы Linux используют shim, из-за поддержки сертификатов, которая позволяет легко обновлять следующий загрузчик без необходимости взаимодействия с пользователем. Как правило, shim используется для запуска GRUB2 — наиболее популярного бутлоадера в Linux.
GRUB2
Чтобы злоумышленники втихую не наделали делов с помощью подписанного загрузчика какого-либо дистрибутива, Red Hat сделал патчи для GRUB2, блокирующие «опасные» функции при включенном Secure Boot: insmod/rmmod, appleloader, linux (заменён linuxefi), multiboot, xnu, memrw, iorw. К модулю chainloader, загружающему произвольные .efi-файлы, дописали собственный загрузчик .efi (PE), без использования команд UEFI LoadImage/StartImage, а также код валидации загружаемых файлов через shim, чтобы сохранялась возможность загрузки файлов, доверенных для shim, но не доверенных с точки зрения UEFI. Почему сделали именно так — непонятно; UEFI позволяет переопределять (хукать) функции проверки загружаемых образов, именно так работает PreLoader, да и в самом shim такая функция имеется, но по умолчанию отключена.Так или иначе, воспользоваться подписанным GRUB из какого-то дистрибутива Linux не получится. Для создания универсальной загрузочной флешки, которая бы не требовала добавление ключей каждого загружаемого файла в доверенные, есть два пути:
- Использование модифицированного GRUB, загружающего EFI-файлы своими силами, без проверки цифровой подписи, и без блокирования модулей;
- Использование собственного пред-загрузчика (второго), переопределяющего функции проверки цифровой подписи UEFI (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)
Второй вариант предпочтительней — загруженные недоверенные программы тоже смогут загружать недоверенные программы (например, можно загружать файлы через UEFI Shell), а в первом варианте загружать всё может только сам GRUB. Модифицируем PreLoader, убрав из него лишний код и разрешив запуск любых файлов.
Итого, архитектура флешки получилась следующая:
______ ______ ______
?¦ ¦ ?¦ ¦ ?¦ ¦
/_¦ ¦ > /_¦ ¦ > /_¦ ¦
¦ ¦ > ¦ ¦ > ¦ ¦
¦ EFI ¦ > ¦ EFI ¦ > ¦ EFI ¦
¦_______¦ ¦_______¦ ¦_______¦
BOOTX64.efi grubx64.efi grubx64_real.efi
(shim) (FileAuthentication (GRUB2)
override)
vvv ^
^
______ ^
?¦ ¦ ¦
/_¦ ¦ ¦
¦ ¦ ===========-
¦ EFI ¦
¦_______¦
MokManager.efi
(Key enrolling
tool)Так появился Super UEFIinSecureBoot Disk.
Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.
Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.
Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2.
Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.
Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.
Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.
Подписанные загрузчики
Мне было интересно, можно ли как-то обойти необходимость добавления ключа через shim при первом запуске. Может, есть какие-то подписанные загрузчики, которые позволяют делать больше, чем рассчитывали авторы?Как оказалось — такие загрузчики есть. Один из них используется в Kaspersky Rescue Disk 18 — загрузочном диске с антивирусным ПО. GRUB с диска позволяет загружать модули (команда insmod), а модули в GRUB — обычный исполняемый код. Пред-загрузчик у диска собственный.
Разумеется, просто так GRUB из диска не загрузит недоверенный код. Необходимо модифицировать модуль chainloader, чтобы GRUB не использовал функции UEFI LoadImage/StartImage, а самостоятельно загружал .efi-файл в память, выполнял релокацию, находил точку входа и переходил по ней. К счастью, почти весь необходимый код есть в репозитории GRUB'а с поддержкой Secure Boot от Red Hat, единственная проблема: код парсинга заголовка PE отсутствует, заголовок парсит и возвращает shim, в ответ на вызов функции через специальный протокол. Это легко исправить, портировав соответствующий код из shim или PreLoader в GRUB.
Так появился Silent UEFIinSecureBoot Disk. Получившаяся архитектура диска выглядит следующим образом:
______ ______ ______
?¦ ¦ ?¦ ¦ ?¦ ¦
/_¦ ¦ /_¦ ¦ > /_¦ ¦
¦ ¦ ¦ ¦ > ¦ ¦
¦ EFI ¦ ¦ EFI ¦ > ¦ EFI ¦
¦_______¦ ¦_______¦ ¦_______¦
BOOTX64.efi grubx64.efi grubx64_real.efi
(Kaspersky (FileAuthentication (GRUB2)
Loader) override)
vvv ^
^
______ ^
?¦ ¦ ¦
/_¦ ¦ ¦
¦ ¦ ===========-
¦ EFI ¦
¦_______¦
fde_ld.efi + custom chain.mod
(Kaspersky GRUB2)Заключение
В этой статье мы выяснили, что существуют недостаточно надежные загрузчики, подписанные ключом Microsoft, разрешающим работу в режиме Secure Boot.С помощью подписанных файлов Kaspersky Rescue Disk мы добились «тихой» загрузки любых недоверенных .efi-файлов при включенном Secure Boot, без необходимости добавления сертификата в UEFI db или shim MOK.
Эти файлы можно использовать как для добрых дел (для загрузки с USB-флешек), так и для злых (для установки буткитов без ведома владельца компьютера).
Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.
Скачать Super UEFIinSecureBoot Disk: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/
ZeroNet разделяет понятия кода и данных сайта: пользовательские данные хранятся в .json-файлах, а при синхронизации импортируются в sqlite-базу данных сайта со стандартизированной схемой, что позволяет делать умопомрачительные вещи: локальный поиск текста по всем когда либо открытым сайтам за миллисекунды, автоматический real-time аналог RSS для всех сайтов разом.
Стандартизированная система аутентификации и авторизации (похожа на OAuth), поддержка работы за NAT и через Tor.
ZeroNet очень быстро работает, дружелюбен к пользователю, имеет современный интерфейс и мелкие, но очень удобные фишки, вроде глобального переключения дневной/ночной темы на сайтах.
Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.
Комментарии (54)
zhovner
01.04.2019 02:20Один из них используется в Kaspersky Rescue Disk 18
Можно засекать через сколько времени будет отозвана подпись загрузчика Касперского?
Как часто вообще вендоры обновляют список отозванных сертификатов в UEFI? Это только с обновлением прошивки материнской платы происходит?
ValdikSS Автор
01.04.2019 02:26Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.
Microsoft распространяет этот лист через Windows Update, на компьютеры с Windows 10. Windows Update вшивает их в материнскую плату.
Prototik
01.04.2019 02:54обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.
Получается, что не сильно то и обязательное?
Evengard
01.04.2019 14:42Ну одно дело revocation list, а другое дело добавление нового trusted сертификата. Одно ограничивает, другое разрешает.
CodeRush
01.04.2019 10:12Чтобы подпись отозвали, проблему надо зарепортить UEFI Security Response Tem.
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
Asparagales
01.04.2019 04:34Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.
Нам и в Одноклассниках неплохо.OneType
01.04.2019 09:44Кому это нам? С этой конторой лучше дело не иметь, чтоб не сесть за лайки и репосты.
LinuxComp
01.04.2019 08:34Большое спасибо за статью, прочитал с интересом. Как раз недавно хотел разобраться что из себя представляет PreLoader.efi, который я обнаружил ковыряясь в ArchLinux'овском iso.
Хотя при чтении было ощущение что где-то подвох (смотрим на календарь :).
CodeRush
01.04.2019 09:44Спасибо за статью, особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.
Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.
В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.LinuxComp
01.04.2019 13:58Ну да, к сожалению. Вообще получается что хотелка ValdikSS (грузить что угодно) противоречит всей изначальной задумке Secure Boot (т. е. не дать загрузить что угодно). А кто этого хочет, тот чаще всего отключает secure boot вместо настройки своих ключей. Например я =( Знаю, что надо по хорошему всё сделать, и статьи про это у меня в закладках давно, но руки так и не дошли пока.
CodeRush А можно тебе как знатоку UEFI задать оффтопный вопрос:
1) Я вот никогда не видел ноутбука с поддержкой мыши в uefi setup. Все что я видел мимикрируют под интерфейс legacy bios. А на десктопах всё наоборот. Почему так?
2) Если не ошибаюсь, ты где-то говорил что uefi позволяет существенно сократить время загрузки системы при использовании raid контроллеров. Это как-то связано с выбором типа OpROM (Legacy/Uefi) в uefi setup?CodeRush
01.04.2019 17:501) Полно таких ноутбуков, а под старый текстовый интерфейс мимикрируют потому, что IBV так захотели. На десктопах давно уже AMI правит бал, и потому там давно уже вакханалия с OpenGL в Setup и GIFами анимированными, а на ноутбуках еще используют Phoenix и Insyde, которые по умолчанию выглядят «как встарья», и которые надо переделывать под мышь самому. Dell, к примеру, переделывает, а другие не парятся.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.LinuxComp
02.04.2019 02:381) Ясно. Я как раз видел ноуты с прошивками от Phoenix и Insyde, и Dell'овские не попадались, потому спросил. А кто определяет что нравится людям? Отдел маркетинга? Мне эти блёстки не нужны, просто любопытно было. Меня поразило однажды: увидел на одном десктопе в uefi интерфейсе Веб браузер (!) и Skype (!!!). Нахрена??? Предполагалось что по нему будет звонить те, кому лень поставить OS? Это риторический вопрос конечно.
А ещё AMI я вижу на серверах (supermicro), но там нет этого всего с OpenGL. Я вообще CSM давно бы отключил везде, но сейчас его актуальность обусловлена только необходимостью обновления «bios» из dos'а. Почему-то производитель предлагает инструкции под DOS. Хотя я в интернете видел прошивальщик AMI, работающий через uefi shell. Я его не пробовал ещё (как-то стрёмно :)), но хотел более внимательно изучить. Как считаешь, можно ли просто так взять его, и прописав такие же параметры как прописаны в батниках с досовским прошивальщиком обновить uefi?
2) Ну я могу провести бенчмарки. Я просто хотел узнать, правильно ли что я переключал эту опцию или могло что-то ещё влиять. Ты говоришь что это зависит от количества подключенных к контроллеру дисков? Я просто переключать уже пробовал, но разницы особо не почувствовал — что так, что так раздражающе долго платформа перезапускается. Хотя опять же, у supermicro на некоторых материнках как-то криво сделано в настройках что не поймёшь, какой OROM в итоге загрузился.JerleShannara
02.04.2019 03:59По первому пункту у асрока в их интерфейсе висит аж настройка VPN-а, ну а в пример серверных частей, если 3d со стразами и пукающими единорогами не вымораживает, то можно посмотреть на HP, графики в setup там добавили по минимуму, но вот прошивка управления это линукс, в котором крутятся иксы, в которых крутится фаерфокс(вроде как он), плюс всякое «прикручу везде jsonчик, оберну я всё в ajax». Ну и (спорно весьма)приятная фишка — опятьже через эту утиль HPE предлагает накатывать операционную систему (при этом оно из прошивки вытаскивает туда драйвера).
ValdikSS Автор
01.04.2019 14:40особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.
А он не единственный такой ;)CodeRush
01.04.2019 17:54Никто другого и не ждал, за 7 лет с запуска UEFI CA им успели подписать такое количество всякой дырявой фигни, что доверять ему теперь — то еще решение. При этом не будешь доверять — OROMы перестанут запускаться, т.е. технология сразу переходит из разряда «включил и работает» в «требует постоянного внимания администратора», и потому отключать ее начнут теперь еще более яростно.
JerleShannara
02.04.2019 01:47+1Как и говорилось, что хочешь безопасности — удаляй дефолтные ключи и переподписывай всё (и опромы) на своём.
7313
01.04.2019 10:21С одной стороны спасибо конечно, но с другой стороны как-то действительно можно скачать с ZeroNet?
Просто в описании все ссылки ведут на github, а в разделе релизов
http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/releases/?1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv
пусто?ValdikSS Автор
01.04.2019 10:21Репозиторий silent, файлы в папке filesystem_kaspersky.
7313
01.04.2019 10:42так в первую очередь попробовал, но кнопка Download не работает в папках, а попытка взять zip по аналогии с гитхабом не удалась…
ValdikSS Автор
01.04.2019 10:46Вверху есть кнопка clone, которая показывает команду для выполнения
git clone.
git clone $path_to_zeronet_data_folder/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/silent-uefiinsecureboot-disk.git -b silent
OlegAndr
01.04.2019 19:25Responsible Disclosure прямо налицо.
ValdikSS Автор
01.04.2019 20:07-1По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению. Она нишевая, способна приченить урон в ограниченных случаях и особых условиях.
Со стороны Касперского устранить проблему нельзя, только писать в UEFI, с просьбой о добавлении хеша или сертификата в список отзыва.
Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.OlegAndr
02.04.2019 11:23-2Подумайте ещё раз.
Прежде всего интересно, сколько времени займет обновление списка отзыва в случае публичного сообщения о проблеме.
Конечно интересно! Ретроспективный отзыв сертификата, который инвалидирует подписанные файлы за последние 3 года- это же так весело, что может пойти не так? Ведь вы же учли все возможные сценарии использования!ValdikSS Автор
02.04.2019 13:49В UEFI dbx можно добавлять не только сертификаты, но и хеши конкретных запускаемых через StartImage файлов. Именно так было сделано с загрузчиками Windows в 2016.
Можно отозвать только GRUB (fde_ld.efi), разрешающий загрузку модулей, но не сам пред-загрузчик Касперского (BOOTX64.efi).
anatolymik
02.04.2019 14:20Где-то выше, коллега по цеху упоминал что на практике все выродилось в то, что ШИМ все делали не безопасно. Справедливо и обратное утверждение. UEFI реализован чуть лучше чем плохо. Гарантии даете что этот механизм будет работать надежно? И что никто не пострадает?
OlegAndr
02.04.2019 16:09Любой отзыв это серьёзный риск. У меня был случай когда ошибочно отозвали сертификат не с указанной даты а ретроспективно. Просто CA пропустило мимо мозга дату отзыва. Пока они исправили ошибку было не очень приятно. А здесь, где процедуры выпуска апдейтов третьими лицами ещё задействованы…
ValdikSS Автор
02.04.2019 14:21+2Вы работаете в Касперском?
Правильно ли я понимаю, судя по названию файла fde_ld.efi, этот загрузчик был создан для Kaspersky Endpoint Business, и был переиспользован для Kaspersky Rescue Disk?
Отзыв этого файла сломает загрузку с шифрованного диска в Kaspersky Endpoint Business?
anatolymik
02.04.2019 12:29-1По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению.
Зачем тогда надо было статью об этом писать?
И да, проблема значительная. Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикаю. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем. Видимо плюсики дороже.
Ждем Petya2.ValdikSS Автор
02.04.2019 15:09Зачем тогда надо было статью об этом писать?
Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно. Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны. Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика. Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.
В SSL-сертификатами в вебе было то же самое, пока не сделали Certificate Transparency и различные системы обнаружения аномалий с сертификатами в браузерах.
Как видно, Kaspersky подписал обычный GRUB, вероятно, даже не задумываясь, что делает что-то неправильно. И загрузчик от Касперского — не единственный такой.
Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
Я за два года до публикации о баге в NTFS отрапортовал в Microsoft и дважды спросил разрешения на публикацию. Я конечно не люблю порой корпорации за их поведение, и не редко бывают причины так действовать, но простые пользователи тут не причем.
Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС. Такая сложная процедура бессмысленна для атак на обычных пользователей — если у злоумышленника и так есть администраторский доступ в ОС, он просто выполнит необходимые действия в ОС, а не через загрузчик.
Это имеет смысл только при узконаправленных целевых атаках с дополнительным сокрытием (APT), которые не применяются массово, и не направленых на обычных пользователей.anatolymik
02.04.2019 15:36Чтобы обратить внимание на существование подписанных загрузчиков, позволяющих загружать что угодно.
Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали. А простым пользователям эта информация никакой ценности не несет.
Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны.
Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.
Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика.
Отвечать должна Microsoft(по совести). Т.к. на себя замкнула подпись. Но только это к ним вопросы должны быть. Направленные.
Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.
Это не так. Было бы желание. Большинство тонкостей можно выяснить, работая с модулем как с черным ящиком.
даже не задумываясь, что делает что-то неправильно
А вы когда делаете что-то не так всегда это сознаете?
Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
Никак вообще. Деньги только в большем объеме брать будут.
Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
Нет, нужен физический доступ к ПК. Она не критичная. А популярной она стала только потому что собрались любители покритиковать. Ну и любители пополнения контентов своих сайтов. Раздули из мухи слона. Всем нужна истерика.
На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС.
Видимо Petya как-то иначе работал. Пойду изучать.ValdikSS Автор
02.04.2019 16:06-1Чье внимание? Разработчики и комитет UEFI и так все это знают. Вы нам нового ничего не рассказали.
Для меня это новая информация. Раз комитет UEFI знает и не отзывает, то и этот не отзовут? В чем тогда смысл прохождения аудита для получения подписи Secure Boot?
Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.
Не согласен с вами. Каких-то серьезных проблем с точки зрения использования не наблюдал, что на десктопах и ноутбуках, что на VPS (некоторые хостеры используют UEFI).
Это не так. Было бы желание. Большинство тонкостей можно выяснить, работая с модулем как с черным ящиком.
Не понял, о чем вы. Я о том, что Microsoft, по-видимому, интересует только пред-загрузчик (тот, который они будут подписывать), а payload, который он загружает, не проверяется.
А вы когда делаете что-то не так всегда это сознаете?
Если это что-то настолько серьезного уровня, как глобальная подпись файла, которая может повлиять на всю технологию в целом, то я либо попрошу всё сделать компетентных людей, либо трижды удостоверюсь, что все сделал правильно, и попрошу компетентных людей перепроверить, чтобы не добавлять проблем ни себе, ни остальным.
Вероятно, некоторые думают иначе, и им важно только то, чтобы их ПО запускалось с включенным Secure Boot.
Нет, нужен физический доступ к ПК.
Речь о той уязвимости, которая описана в вашей статье «Баг в NTFS, или как подвесить всю систему»? Для чего там нужен физический доступ?
Видимо Petya как-то иначе работал. Пойду изучать.
Либо происходила перезапись MBR с администраторскими правами, либо просто шифровались документы пользователя из ОС. NotPetya ещё применял эксплоит EternalBlue, для получения прав администратора.
https://en.wikipedia.org/wiki/Petya_(malware)#Operation
OlegAndr
02.04.2019 16:13>Сейчас Microsoft требует использования Extended Validation-сертификатов, вместо самоподписанных, возможно, это как-то повлияет на ситуацию.
Для EFI-модулей всегда было требование на EV сертификаты. Там ещё и процесс нетривиальный.
anatolymik
02.04.2019 10:55Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: 127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/
Я извиняюсь, а Silent в ZeroNet был залит по каким-то соображениям безопасности?
Prototik
Великолепно! Ещё раз доказывает странность такого вот хитровыделанного vendor lock-in.
ValdikSS Автор
Это не Vendor Lock. Secure Boot — разумная технология, обеспечивающая первый бастион защиты операционной системы, которая может в том числе защищать и запущенную ОС, если ОС поддерживает Secure Boot, например, в Linux можно настроить загрузку только доверенных модулей ядра, ключ которых есть в UEFI db.
Её можно отключить на всех магазинных платах, если она вам не нужна.
Prototik
Под вендор локом я подразумевал прошивку ключей Microsoft по умолчанию. Почему они?
Ладно ещё, когда компьютер поставляется в сборе с предустановленной Windows, но в других случаях…
Я конечно понимаю, что
хомянепродвинутым пользователям так проще, но можно же было придумать какой-то другой путь, например как в ssh: при попытке загрузки бинарника с неизвестным ключом UEFI бы спрашивал «а вы точно доверяете вот этому-этому?».У самого настроен «кошерный» secure boot с правильными ключами, без всяких шимов.
dartraiden
Поэтому, подстраиваются под удобство подавляющего большинства (удобство = не докучать пользователю лишними, с его точки зрения вопросами после каждого обновления загрузчика + хоть как-то защиить его от вредоносного загрузчика), а пара процентов пользователей, которым требуются собственные ключи, явно способны удалить ключи по умолчанию.
Prototik
Ну поэтому я и предложил альтернативу: «Вы доверяете Microsoft Inc? Продолжаем устанавливать Windows?».
Ну или хотя бы не так сильно палились и вшивали бы ключ абстрактной UEFI Signing Foundation, которая бы верифицировала все остальные загрузчики.
А то получается «Каждому родившемуся на территории России сразу выдывать карточку Сбербанка, ну а что, в 90% случаев она ему нужна».
dartraiden
А UEFI Signing Foundation кто-то спросил, хочет ли она этим заниматься?
Вы думаете,Кстати, интересно, наличие сертификатов MS это частная инициатива вендоров или требование спецификации? Если первое, то c UEFI Forum взятки гладки.
хомяпользователи будут читать? Они будут жать «Да» даже в том случае, когда там уже не загрузчик Microsoft, а загрузчик малвари. Именно поэтому и выбрано решение, которое от чайника не требует ничего, а продвинутому пользователю даёт возможность настройки по вкусу.ValdikSS Автор
Насколько знаю, как раз никто не захотел заниматься аудитом и подписью загрузчиков, и всё как-то само передалось Microsoft.
В UEFI требований по сертификатам нет как таковых, требование есть у Microsoft, для сертификации компьютера под Windows 10.
Некоторые материнские платы содержат ключи Canonical и Red Hat.
CaptainFlint
kovserg
И виртуализация есть и jit и minux установлен и ещё куча всего. А платформо-независимых драйверов нет, что бы из коробки всё что впаяно в плату гарантировано работало под любой OS.
А разумным бастионом защиты операционной системы должна была быть флешка на материнке и перемычка на плате, которая апартно запрещает изменять любые данные на ней.
dartraiden
Экономия уже дошла до того, что практически все вендоры начали просто распаивать микросхему на материнке (с выводом гребёнки для программатора) вместо гораздо более удобного варианта «микросхема в кроватке». Видимо, так на несколько центов дешевле.
CodeRush
Добавлю, что это не только удорожает продукт, но и делает автоматические обновления невозможными в принципе, потому что от пользователя требуется нетривиальное (т.е. не «нажмите Ввод») физическое присутствие, которое невозможно обеспечить либо по причине «у пользователя лапки», либо потому, что система установлена в дата-центре в закрытый шкаф.
kovserg
А с чего вы решили что автоматические обновления это хорошо?
(asus live update неплохой пример заботы о пользователях)
Вы в биос в дата центре тоже удаленно заходите?
CodeRush
Удивительный вопрос, я даже несколько теряюсь. Ручные обновления = отсутствие обновлений = известные и эксплуатируемые уязвимости, которые значительно хуже, чем новые, еще не известные и не эксплуатируемые. Если вы готовы сами следить за обновлениями и нести ответственность за безопасность системы — я только за, но вас таких снова три с половиной, а защитить хоть как-нибудь и закрыть хотя бы известные дыры стараются для всех. UEFI Forum разработал и внедрил общих механизм для обновления всех компонентов прошивки — ESRT, которым пользуются клиенты вроде Windows Update и Linux Vendor Firmware Service. Очень жаль, что поддерживаются эти сервисы пока далеко не всеми, потому что нужны они еще вчера.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Stanislavvv
Автоматическое обновление _загрузчика_ будет невозможно.
Почему-то обновление ядра линукса не требует переустановки груба — достаточно поправить в текстовом конфиге, что грузить дальше.
Да и обновление всего остального тоже без проблем.
Система вполне сможет обновлять автоматически, если нет обновлений grub/другого загрузчика (на моей памяти — примерно раз в два года в debian/stable).