Comments 21
@ValdikSS, приколись, как они могут. Я думал, что всякую фигню UEFI CA подписывать, а потом ее героически (неправильно) банить - это максимум того, что эта "индустрия" может, но здесь Insyde превзошли и самих себя, и всех остальных. Очень веселый тамада, и очень интересные конкурсы...
Вторая часть на английском, русскую версию напишу чуть позже.
Ха! На каком-но ноутбуке Lenovo можно было обойти TPM через Driver0001 — не учитывался в PCR.
Написал, вот она: https://habr.com/ru/articles/918192/
Соседи прошивают через стены
Самое приятное, что +/- никто из производителей никогда на миллионах выпущенных устройств это не закроет. Гипотетически, впрочем, можно выпустить +/- универсальный патч и без них.
прикольно )
Я не очень понял в чём собсна уязвимость.
UEFI-биос запустил подписанную винду
Из-под подписанной винды юзер с админскими правами прописал в биос дополнительный сертификат и подписал бинарь
Биос запустил бинарь из пункта 2
На первые два взгляда это просто нормальная работа chain of trust, не?
(Нахмуря брови) С точки зрения "индустрии": правильный chain of trust -- это когда защитились от пользователя со всеми правами. Сказано нельзя, значит прошивка должна быть только с подписями оригинальными от Microsoft + IBV.
С одной стороны это хорошо в плане ограничения урона:
Похерили всё с учетной записи пользователя? Но ОС не тронута.
OS is pwned? Но тогда переустановимся, ведь прошивка не тронута.
Прошивку модифицировали? Ой-ой-ой...
С другой стороны, мы шагаем в дивное будущее, которое уже наступило на смартфонах и других коробочных изделиях, где шаг в сторону -- расстрел. Смотреть в сторону SafetyNet / Play Integrity API.
Тивоизация во всей красе. И не задавайтесь вопросом, почему это Microsoft отказывается подписывать изделия под GPLv3 типа GRUB2.
Так как успели налепить минус:
Из-под подписанной винды юзер с админскими правами прописал в биос дополнительный сертификат и подписал бинарь
Подмена/внедрение иного сертификата должна быть доступна только из заведомо безопасного окружения, т.е. из настроек самой прошивки. У пользователей SecureBoot пароль на вход в прошивку же стоит? Да ведь?
А всё, я понял, дыра в том что если отключить SecureBoot, тогда мы инжектим серт из-под операционки не входящей в chain of trust. И при последующем его включении UEFI pwned. Вопрос снимается.
Secure Boot признан защитить от удалённого злоумышленника, без физического доступа к клавиатуре компьютера.
У пользователя, физически присутствующего около компьютера, есть возможность добавлять какие угодно сертификаты в хранилище через настройки UEFI, либо с помощью сторонних .efi-утилит (для этого нужно перевести Secure Boot в спец. режим setup mode).
А описанный в статье сценарий позволяет обойти хранилище сертификатов (и хранилище отозванных сертификатов) и запустить произвольный .efi-файл без физического присутствия. Из-под Windows, запущенной с включённым Secure Boot без сторонних сертификатов.
Еще даже немного веселее - здесь мы претворяемся частью самой прошивки, и потому наши efi-файлы она запустит даже тогда, когда не стала бы запускать ничего другого, даже если оно в обычном режиме работы проходит все проверки UEFI SecureBoot. Я во второй части уже описал это все подробно на английском, осталось теперь написать то же самое на русском.
При реализации п.2 учтите, что у Secure Boot есть два режима: Standard и Custom.
Например, прошивка моей мат. платы в режиме Standard посылает меня лесом при попытке изменить db, даже при наличии у меня прав суперпользователя в ОС.
Вообще от каких угроз должен в теории защищать SecureBoot? Например, если всё в Linux зашифровано через LUKS, кроме каталога /boot - защитит ли SecureBoot от встраивания кейлоггера в /boot?
Основная угроза, от которой призван защищать UEFI SB - подмена EFI-загрузчика на вредоносный и\или запуск вредоносных исполняемых файлов до либо параллельно с загрузчиком, через механизмы вроде DriverXXXX/DriverOrder, OptionROM и т.п.
В вашем примере, при правильной настройке (т.е. использовании EFI_STUB и встроенного initramfs) - защитит.
Например ещё при загрузке по сети (PXE).
Hydroph0bia (CVE-2025-4275) — тривиальный обход SecureBoot в UEFI-совместимых прошивках на базе платформы Insyde H2O