Исследователями безопасности MY123 и Slipstream был найдена уязвимость в реализации механизма Secure Boot многих устройств, позволяющая полностью обойти требование наличия надлежащим образом подписанного исполняемого кода для запуска на этих устройствах. Это, в частности, означает, что владельцы планшетов с Windows RT вновь получат возможность устанавливать альтернативную операционную систему. Но так же это означает, что и головной боли у системных администраторов прибавится, ведь уязвимость открывает новые возможности для установки руткитов.
Энтузиасты разместили подробную информацию на специальной страничке, оформленной в стиле демо-сцены.
Опция Secure Boot — разрешает и\или запрещает возможность запуска и установки других ОС на данном устройстве.
Secure Boot — это версия протокола загрузки, его работа основана на "зашивании" в BIOS ключей для проверки сигнатур загрузочного кода. Secure Boot отказыватся от выполнения любой загрузки при не совпадении подписей. Данная технология защиты от взлома и нелицензионного использования ОС основана на модульности UEFI (Unified Extensible Firmware Interface ) BIOS. UEFI — предназначена для инициализации оборудования при включении системы и передачи управления загрузчику ОС.
Secure Boot входит в спецификацию UEFI 2.2. Включенный Secure Boot обычно не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, и, по идее, беспокоиться тут не о чем. Однако, неотключаемый Secure Boot есть на планшетах на ARM с предустановленной Windows! А в условиях приближающегося срока окончания поддержки данных устройств пользователи столкнулись с перспективой получить на руках стремительно устаревающий кусок кафельной плитки вместо планшета с весьма приличным железом.
Подробней о функционировании UEFI можно почитать в материале "Немного про UEFI и Secure Boot".
Не было бы счастья, да несчастье помогло. Microsoft практически сами "слили" информацию о способе обхода Secure Boot.
Если попытаться кратко и очень приблизительно описать суть найденной уязвимости, то она заключается в следующем. Модульная архитектура UEFI позволяет последовательную загрузку объектов в память. Microsoft предусмотрели специальную отладочную процедуру, предназначенную для производителей устройств и разработчиков драйверов. Эта процедура позволяет загрузить самоподписанный бинарный код в обход обязательных проверок. На устройствах под управлением Windows с залоченым загрузчиком, где эта процедура отсутствует, ее можно попытаться добавить самому. О самой процедуре и способах ее добавления стало известно в результате исследования относительно свежих пакетов обновления Windows (рэдстоун, привет!).
Фактически, мы имеем дело с преднамеренно внедренным бэкдором во все варианты дистрибутива Windows начиная с 8, а исследователи всего лишь нашли "золотой ключик" от секретного театра, "оставленный нерадивым хозяином на стойке в баре".
Ранее сообщалось, что Microsoft удалила из Windows RT встроенный бэкдор, который позволяет обойти Secure Boot и установить Linux, однако на самом деле это не так. Это были всего лишь полумеры. Характер проблемы таков, что не позволяет действительно закрыть уязвимость, не поломав при этом "безопасную" загрузку для множества уже существующих носителей информации.
Комментарии (39)
CodeRush
11.08.2016 06:03+2Устраняется эта «неустранимая» уязвимость на всех машинах с ключом Microsoft KEK тем же обновлением, который закрывает уязвимость в загрузчике, путем добавления хешей уязвимых загрузчиков в переменную dbx, что запрещает их загрузку. Если же у вас свой собственный ключ в KEK — добавьте эти хеши самостоятельно.
Jeditobe
11.08.2016 09:31+2it'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 не пойдет на «устранение» этой уязвимости, потому, что ущерб от устранения будет превышать потенциальную выгоду на порядки. Все, что они будут делать, это пытаться затруднить всем жизнь, но не более того.CodeRush
11.08.2016 16:17+1Деваться им в этой ситуации некуда, так что пойдут как миленькие. У меня сейчас нет тестовой системы с Windows, чтобы проверить это утверждение, но я обязательно вернусь к этому вопросу, когда она появится.
Laney1
11.08.2016 09:16+1поправьте заголовок плиз. Это уязвимость не в Secure Boot, а в загрузчике Windows.
Jeditobe
11.08.2016 09:26+2который является непосредственным участником механизма Secure Boot. А если учесть, что Microsoft была главным идеологом и является главным пользователем технологии с подавляющим численным перевесом над другими пользователями. То все же можно говорить о компрометации Secure Boot.
Laney1
11.08.2016 09:38+2покажите раздел спецификации UEFI, в котором прописан механизм из статьи. Если уж на то пошло, то большинство линуксовых дистров (например, Ubuntu до версии 16.04) прекрасно позволяет запускать неподписанные драйверы при включенном Secure Boot, и там никто не считает это уязвимостью.
Jeditobe
11.08.2016 09:46+1Ключи MS внедрены в 99% материнских плат девайсов с поддержкой UEFI. И даже дистрибутивы Линукса используют именно эти ключи, а не свои собственные. Поэтому всегда есть возможность задействовать уязвимость через использование загрузчика Microsoft, даже если стоит Линукс.
Laney1
11.08.2016 09:50+2или использовать загрузчик linux, даже если стоит загрузчик Microsoft с исправленной уязвимостью.
Короче — исправьте заголовок, и не производите впечатление очередного необъективного MS-хейтераJeditobe
11.08.2016 09:58Я подкоректировал заголовок, но несколько иначе. И я не вижу ничего плохого, чтобы не быть хотя бы чуть-чуть MS-хейтером.
Laney1
11.08.2016 10:30+9еще раз, объясняю на пальцах.
Механизм Secure Boot заключается в том, чтобы передавать управление только загрузчикам, заверенным подписью из белого списка.
Загрузчик, в свою очередь, может делать все что пожелает, это не является частью спецификации.
Некоторые загрузчики также запускают с наивысшими полномочиями только код с подписью из собственного белого списка (возможно, не совпадающего с тем что прописан в BIOS), некоторые — запускают все подряд.
Исследователи обнаружили, что загрузчик Windows (bootmrgw.efi) позволяет запускать все подряд. Почему заголовок статьи звучит как «уязвимость в механизме Secure Boot», хотя этот механизм тут вообще не при чем? Это уязвимость следующего этапа, за который Secure Boot не отвечает и отвечать не может.
И я не вижу ничего плохого, чтобы не быть хотя бы чуть-чуть MS-хейтером
то есть вы вводите читателей в заблуждение не из-за собственного непонимания проблемы, а намеренно, потому что являетесь MS-хейтером?Jeditobe
11.08.2016 10:47Secure boot для введения ограничений на возможность исполнения произвольного кода:
* ограничение списка ОС, которые можно запустить на девайсе;
* предотвращение запуска руткитов и буткитов.
Найденная уязвимость снимает оба ограничения полностью. Да, сама она лежит за пределами спецификаций Secure boot, но при этом делает Secure boot полностью бесполезным, т.е. компрометирует его.
Гладко было на бумаге, да забыли про овраги. Secure boot не уязвим на бумаге, но все существующие (или как минимум подавляющее большинство) его реализации оказались скомпрометированы. И скомпрометированы они не кем нибудь, а действиями самого главного локомотива всей технологии — компанией Microsoft.
Wesha
16.08.2016 02:20Сопротивление не обязательно бесполезно.
Не могу быстро найти статью, так что пишу по памяти.
В какой-то лаборатории игрались с генетическими алгоритмами, пытаясь получить FPGA, выполняющую роль мультивибратора, выдающего частоту в 1 Гц. Как всегда с генетическими методами, на выходе получилась жуткая мешанина из компонентов, не описуемая никакой логикой, которая тем не менее выдавала требуемую частоту. Но наибольший ужас вызывал транзистор, подключеный к остальной схеме ОДНИМ выводом.
"Это что за хрень!" — сказали экспериментаторы и убрали его из схемы. Частота на выходе пропала! 8-O Подключили обратно — появилась!
Они долго ломали голову, пока наконец не нашли разгадку. Подключенный одним выводом транзистор выполнял роль антенны, которая принимала выдаваемую каким-то плохо заэкранированным прибором в соседней комнате как раз на требуемой частоте.
ChALkeRx
11.08.2016 10:49+4Знаете, если утечёт приватная часть сертификата какой-нибудь комоды, которой можно будет подписать что угодно и которую по каким-то причинам решат не отзывать — это будет проблема комоды лично или TLS в целом? Это невероятный сценарий (особенно часть «решат не отзывать»), но здесь мы наблюдаем именно это.
Насколько я понимаю, все или подавляющее большинство устройств доверяют уязвимому bootmrgw.efi. bootmrgw.efi доверяет чему угодно. Ни один из компонентов этой цепочки в ближайшем будущем не починят, если верить авторам.
Это проблема системы как таковой.
Jeditobe
11.08.2016 10:58+1Я прям вижу, как разворачивают кризисный центр, а в центральные офисы Microsoft уже едут сотни срочных посылок с BDSM-атрибутикой внутри.
Кто-то вел себя очень плохо последние несколько лет и должен быть наказан.
Laney1
11.08.2016 12:06+5Насколько я понимаю, все или подавляющее большинство устройств доверяют уязвимому bootmrgw.efi. bootmrgw.efi доверяет чему угодно. Ни один из компонентов этой цепочки в ближайшем будущем не починят, если верить авторам.
статья называется «уязвимость в Secure Boot», а не «уязвимость в bootmgrw.efi, shim, preloader, и бог знает где еще». Где тут уязвимость в Secure Boot?Jeditobe
11.08.2016 13:12+1Ваша точка зрения мне понятна, ок. Но как автор поста, я могу транслировать свое видение ситуации. Вашу точку зрения смогут увидеть все, кто зайдет в комментарии.
dmitry_dvm
11.08.2016 11:01Осталось за малым — придумать, как поставить вин10 на Limia 2520 и я сразу же ее куплю.
Ivan_83
11.08.2016 17:57Вот и хорошо, поменьше секуребута — жизнь юзера будет лучше.
Вся эта хрень с безопасной загрузкой нужна была только корпорациям, чтобы юзеры могли грузить только их платную ОС и не могли грузить свои дрова для обхода DRM.
Простому юзеру это мешало ставить кряки к венде, не простым юзерам это мешало ставить любимую/любую ОС.
У простого юзера как был зоопарк в венде так и остался, ему от наличия/отсутствия руткитов в системе вообще ничего не меняется.
JerleShannara
11.08.2016 19:13+1От SecureBoot есть толк, если вы очень серьёзно озабочены безопасностью вашего ПК и у вас таки присутствует паранойя. Тогда вы спокойно убиваете в UEFI все не нравящиеся вам ключи, ставите свои, берёте ваш любимый и защищённый дистибутив операционки и подписываете его загрузчик своим ключём. Всё, у вас всё схвачено — ничего, кроме вашего загрузчика запуститься не может.
Ivan_83
12.08.2016 19:38-3Наивный.
От чего по твоему защищает секуре бут и кого он защищает? Думал?
Совершенно определённо он никак не защитит тебя от того что кто то у тебя вытащит винт и запишет туда всё что захочет (в том числе и то что запустится после бута) или прочитает.
Совершенно точно там есть «AWARDSW» для своих.
При этом я доверяю своей ОС.
Я могу в 4-5 команд перезаписать загрузки обратно.
(и у меня нет проблем с загрузкой дров — гружу всё что я хочу)
Arrest
13.08.2016 00:40Совершенно определённо он никак не защитит тебя от того что кто то у тебя вытащит винт и запишет туда всё что захочет (в том числе и то что запустится после бута) или прочитает.
Да, но то, что он запишет, не будет подписано вашим ключом и не будет запущено. Да, прочитает, но если вы пошли на то, чтобы перезаписать ключи в UEFI, то, скорее всего, диск у вас зашифрован.
Совершенно точно там есть «AWARDSW» для своих.
Это нефальсифицируемый аргумент.
Я могу в 4-5 команд перезаписать загрузки обратно.
С UEFI это можно сделать в одну ;)
Ivan_83
13.08.2016 21:28Не надо путать то что якобы возможно с тем что на самом деле.
Да, в теории возможно сделать прописать и подписать свой загрузчик, который спрашивает пароль от зашифрованного диска.
В теории и это даже не надо, ибо диски сами умеют аппаратно шифровать.
На практике
1. Секуребут включён везде где венда, при этом никакого шифрования там нет, и вся эта профанация только для того чтобы юзер не мог загрузить что то другое, либо не мог через лоадер загрузить слик тем самым хакнув венду, или не мог загрузить свои дрова, дабы ненароком не обойти дрм.
Все сказки про защиту от вирусов — херня, вирусам и так хватает прав админа или даже юзера чтобы делать свои дела.
2. Безумие слепо доверять в таких вопросах, да ещё и зарубежным компаниям, для которых мы просто никто в плане последствий/обратной связи. Это и про аппаратное шифрование диска и про закладки в биосе.
Я считаю что производитель должен доказывать безопасность решения, а не просто назвал секуребут и мы такие ему поверили.
2 JerleShannara
Откуда такая наивность берётся!?
Почему разумный человек должен доверять коду уефи который он в жизни никогда не видел и который никто не аудитил?
Я молчу про Intel ME, который клал с прибором на уефи.
Много проще держать диски зашифрованными, в качестве крайней меры, а комп просто физически делать недоступным + иметь пачку индикаторов вторжения, чтобы в случае если до компа добрались то знать об этом.JerleShannara
16.08.2016 20:411) TianoCore(UDK) сто лет как доступен каждому ленивцу.
2) Параноики уже давно слили Aptio трёхлетней давности и просмотрели его (ужаснувшись от качества кода). Плюс никто не запрещает вам вооружиться Radare2/IDA Pro и исследовать сей замечательный код, наплевав на его закрытость.
3) AMT/ME спокойно вырезается на <45 сериях интела под корень и отсутствует на eKabini — параноики спокойно обходятся не самым новым железом.
4) Для вас могу порекомендовать Lenovo X200/T400/T500 с прошитым LibreBoot, вам понравится, ни единого бинарного блоба кроме EC контроллера (а может и его уже отреверсили), никакого секурбута, шифрование можно начать с самого начала.
JerleShannara
13.08.2016 13:55+1Секурбут является одним из звеньев защиты. Как и полное шифрование диска (фразу про паранойю надо было читать внимательнее). Как и хранение ключей от этого диска на другом носителе. Как и загрузчик, который далее проверяет то, что он грузит. И обезопасив себя таким образом (и опломбировав сам системный блок + отключив программно запись в spi rom) вы спокойно отправляетесь на встречу с другим параноиком для обсуждения каких-либо важных проблем, не опасаясь, что за время вашего отсутствия злобное АНБ/КГБ/ФСБ/Рептилоиды/ЖителиНибиру сумеет вам что-то подменить, перезаписать ваш ефи и т.д.
ChALkeRx
14.08.2016 08:35Если бы секурбут нужен был для защиты пользователя, а не от пользователя, то у пользователя была бы возможность его отключить, всегда, на всех устройствах.
Или не включать вообще из коробки (в зависимости от типа устройства) — всё равно смысла от него без ограничения доступа к настройкам UEFI нет никакого.
Больше того, «защита пользователя» в текущем виде слепо верит всему, что подписала третья сторона в лице МС. Даже флаг за паролем в настройках UEFI, который просто блокирует любые изменения загрузчика (сверкой подписи) был бы лучше с точки зрения безопасности пользователя.
JerleShannara
14.08.2016 14:54+1А я где-то утверждал, что он только для пользователя? Это как с кухонным ножом, можно нарезать стейки(для пользователя), а можно и соседа зарезать(от пользователя). Тот факт, что были девайсы, которые были залочены под определенную операционку я не отрицаю, другое дело, что у заинтересованных пользователей был выбор — брать или не брать такой вендор-лок себе.
«Изкаропки» — сколько я железа не брал, везде была как минимум галочка разрешения/запрещения этого секурбута. Даже на серверах(супермикро). Даже на ноутах ленововских(T и X серии).
Про слепую веру — прочитайте ещё раз мой коммент, с которого этот срач начался, более внимательно.
wolfykey
11.08.2016 23:38Помогите поставить андроид на ASUS VivoTab Smart me400cl. С флешки ничего не запускается, только винда( А тут так понимаю появился способ?
RussianNeuroMancer
12.08.2016 02:14С флешки не запускается наверное из-за 32-разрядного UEFI, но это вопрос решаемый, и загрузив установочный образ той же Ubuntu Gnome 16.04 по одной из инструкций, написанных для устройств на BayTrail, вы сможете получить на вашем me400cl 32-разрядный GRUB в качестве загрузчика, который можно будет использовать для запуска различных ОС. Далее понадобиться раскатать на свободное место (которое нужно было оставить при установке Убунты) раздел с Android x86 (образ которого можно подготовить на другом компьютере или с помощью виртуальной машины) и добавить в конфиг GRUB пункт загрузк Android x86 с этого раздела.
Все что выше — это была простая часть (и возможно последние версии 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 ваша проблема. Ставьте Десятку, тот чудо-драйвер с форума Интел, да избавляйтесь от этого железа через Авито. Перспектив с ним никаких, света в конце туннеля не видно, а проблем ворох.
rockin
Это просто отличная новость. У меня нет слов.