Comments 41
О, спасибо, что разместили тут эту новость.
И да, это просто прелестно.
Особенности перевода. Она не «неустранимая», а «неустранимая без поломки большого количества существующих сейчас загрузочных медиа (дисков/флэшек/рекавери)».
it'd be impossible in practise for MS to revoke every bootmgr
earlier than a certain point, as they'd break install media, recovery partitions,
backups, etc.
Это даже не особенность перевода, это написано в оригинале прямым текстом. Microsoft не пойдет на «устранение» этой уязвимости, потому, что ущерб от устранения будет превышать потенциальную выгоду на порядки. Все, что они будут делать, это пытаться затруднить всем жизнь, но не более того.
* ограничение списка ОС, которые можно запустить на девайсе;
* предотвращение запуска руткитов и буткитов.
Найденная уязвимость снимает оба ограничения полностью. Да, сама она лежит за пределами спецификаций Secure boot, но при этом делает Secure boot полностью бесполезным, т.е. компрометирует его.
Гладко было на бумаге, да забыли про овраги. Secure boot не уязвим на бумаге, но все существующие (или как минимум подавляющее большинство) его реализации оказались скомпрометированы. И скомпрометированы они не кем нибудь, а действиями самого главного локомотива всей технологии — компанией Microsoft.
Сопротивление не обязательно бесполезно.
Не могу быстро найти статью, так что пишу по памяти.
В какой-то лаборатории игрались с генетическими алгоритмами, пытаясь получить FPGA, выполняющую роль мультивибратора, выдающего частоту в 1 Гц. Как всегда с генетическими методами, на выходе получилась жуткая мешанина из компонентов, не описуемая никакой логикой, которая тем не менее выдавала требуемую частоту. Но наибольший ужас вызывал транзистор, подключеный к остальной схеме ОДНИМ выводом.
"Это что за хрень!" — сказали экспериментаторы и убрали его из схемы. Частота на выходе пропала! 8-O Подключили обратно — появилась!
Они долго ломали голову, пока наконец не нашли разгадку. Подключенный одним выводом транзистор выполнял роль антенны, которая принимала выдаваемую каким-то плохо заэкранированным прибором в соседней комнате как раз на требуемой частоте.
Знаете, если утечёт приватная часть сертификата какой-нибудь комоды, которой можно будет подписать что угодно и которую по каким-то причинам решат не отзывать — это будет проблема комоды лично или TLS в целом? Это невероятный сценарий (особенно часть «решат не отзывать»), но здесь мы наблюдаем именно это.
Насколько я понимаю, все или подавляющее большинство устройств доверяют уязвимому bootmrgw.efi. bootmrgw.efi доверяет чему угодно. Ни один из компонентов этой цепочки в ближайшем будущем не починят, если верить авторам.
Это проблема системы как таковой.
Совершенно определённо он никак не защитит тебя от того что кто то у тебя вытащит винт и запишет туда всё что захочет (в том числе и то что запустится после бута) или прочитает.
Да, но то, что он запишет, не будет подписано вашим ключом и не будет запущено. Да, прочитает, но если вы пошли на то, чтобы перезаписать ключи в UEFI, то, скорее всего, диск у вас зашифрован.
Совершенно точно там есть «AWARDSW» для своих.
Это нефальсифицируемый аргумент.
Я могу в 4-5 команд перезаписать загрузки обратно.
С UEFI это можно сделать в одну ;)
2) Параноики уже давно слили Aptio трёхлетней давности и просмотрели его (ужаснувшись от качества кода). Плюс никто не запрещает вам вооружиться Radare2/IDA Pro и исследовать сей замечательный код, наплевав на его закрытость.
3) AMT/ME спокойно вырезается на <45 сериях интела под корень и отсутствует на eKabini — параноики спокойно обходятся не самым новым железом.
4) Для вас могу порекомендовать Lenovo X200/T400/T500 с прошитым LibreBoot, вам понравится, ни единого бинарного блоба кроме EC контроллера (а может и его уже отреверсили), никакого секурбута, шифрование можно начать с самого начала.
Если бы секурбут нужен был для защиты пользователя, а не от пользователя, то у пользователя была бы возможность его отключить, всегда, на всех устройствах.
Или не включать вообще из коробки (в зависимости от типа устройства) — всё равно смысла от него без ограничения доступа к настройкам UEFI нет никакого.
Больше того, «защита пользователя» в текущем виде слепо верит всему, что подписала третья сторона в лице МС. Даже флаг за паролем в настройках UEFI, который просто блокирует любые изменения загрузчика (сверкой подписи) был бы лучше с точки зрения безопасности пользователя.
«Изкаропки» — сколько я железа не брал, везде была как минимум галочка разрешения/запрещения этого секурбута. Даже на серверах(супермикро). Даже на ноутах ленововских(T и X серии).
Про слепую веру — прочитайте ещё раз мой коммент, с которого этот срач начался, более внимательно.
Все что выше — это была простая часть (и возможно последние версии Android x86 сами умеют ставить 32-разрядный GRUB на 32-разрядных UEFI, не знаю — проверьте). Сложности начинаются с того, что в процессорах линейки Intel CloverTrail используется PowerVR SGX 54x вместо видеокарты. Насколько мне известно, сборки видеодрайвера PowerVR SGX есть только для Windows 8 x86, Ubuntu 12.04.0 x86, Android ARM. А вот сборки для Android x86 не существует, как не существует сборки для новой версии Ubuntu. В Windows 10 с Windows Update ставится последняя версия, вышедшая для Восьмерки, и народ на форумах Интела жалуется на проблемы с ней, а вот тут https://communities.intel.com/message/375766#375766 человек пишет, что какая-то старая версия драйвера у него работает стабильнее последней. Плюс совершенно непонятно, какой уровень поддержки остальной переферии вашего устройства в Linux, очень возможно, что ситуация там не намного лучше, чем с видеокартой, ведь устройства на CloverTrail из-за их видеокарты были проблемные изначально, и насколько я могу судить по форумам, сообществами энтузиастов GNU/Linux и Android они были проигнорированы, а значит рассчитывать на хороший уровень поддержки не приходиться.
В общем, не в Secure Boot ваша проблема. Ставьте Десятку, тот чудо-драйвер с форума Интел, да избавляйтесь от этого железа через Авито. Перспектив с ним никаких, света в конце туннеля не видно, а проблем ворох.
Золотой ключик — неустранимая возможность полного обхода Secure Boot на большинстве Windows-устройств