Boot Failure Guard что это за пункт в биосе?
Эй хеллоу! Например вы решили разогнать свой комп. Похвально. Но если комп не хочет запускаться на повышенной частоте, то технология Boot Failure Guard (B.F.G) предложит вам безопасный запуск и выдаст экран настроек.
Технология есть на материнках AsRock, может и на других также присутствует. И вроде как технология включена по умолчанию для всех плат AsRock.
Я написал о технологии, скорее всего пункт в биосе имеет такое же значение.
Есть еще настройка Boot Failure Guard Count — позволяет задать количество попыток загрузиться после изменения настроек для разгона. Например можно указать значение 2 — это означает, что если материнка 2 раза пыталась загрузиться и ничего не получилось, то она сбивает настройки биоса и загружается уже с безопасными настройками. Как по мне — полезная функция.
На заметку. Boot Failure Guard Count переводится — подсчет очков сбоев при загрузке (дословно). Boot Failure Guard — защита от сбоев при загрузке
Мой вывод об использовании Boot Failure Guard:
При возникновении проблем, если что-то настроили и забыли что, если система сбоит, зависает и есть подозрение что все это из-за настроек биоса — сбросьте настройки при помощи Load Optimal Defaults. Пункт обычно находится в разделе Exit (выход).
On-Demand Clock Modulation что это?
On-Demand Clock Modulation (ODCM) — устаревшая технология модуляции тактовой частоты процессора по запросу. Простыми словами — снижение частоты при перегреве, то есть что-то вроде троттлинга. Если процессор перегревается, то снижение частоты приведет к снижению температуры.
Я нашел информацию в одном журнале. Толком что имеется ввиду — не знаю. Похоже на принудительный пропуск тактов. Но опять же — я не могу точно понять. А не могу, потому что инфа была на английском, я перевел на русский.. и вот перевод:
Еще из-за включенной функции могут быть ошибки в старых играх. Например есть какая-то ошибка 200 в игре Jazz Rabbit 1994 и причина именно в On-Demand Clock Modulation. Странно, но вроде бы это относится и к игре Dota 2 — могут быть глюки при включенной функции.
Технологией On-Demand Clock Modulation можно как-то управлять. Умеют это делать например программы OverSoft CPU Informer, RightMark CPU Clock Utility.
Опция в биосе и программы OverSoft CPU Informer и RightMark CPU Clock Utility
Intel SpeedStep что это?
Enhanced Intel SpeedStep Technology (EIST) — технология энергосбережения процессоров. Принцип работы — изменение частоты и напряжения. Изменять частоту, при включенной опции Intel SpeedStep, можно из под Windows — при помощи той или иной программы, или используя инструменты самой операционки (в дополнительных параметрах питания можно ограничить максимальную частоту).
Intel SpeedStep это от Intel, не знаю когда появилась, но в Pentium 4 она уже была. У AMD есть тоже своя технология — Cool-n-Quiet (переводится как Прохлада и тишина), впервые появилась в Athlon 64.
А если не включать? Тогда.. в общем смотрите:
При включенной технологии Intel SpeedStep ограничить частоту процессора в Windows можно этой настройкой:
Значения опции — Disabled (Отключено), Enabled (Включено) и Auto.
Intel SpeedStep в биосе
Фух, вот мы и разобрались с некоторыми опциями. Желаю вам удачи и не хулиганьте там в биосе)) До новых встреч!
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
Уязвимости в некоторых имплементациях BIOS позволяют обойти Intel Boot Guard и Intel BIOS Guard
Linux для хакера
В августе 2017 года, на конференции Black Hat USA 2017, специалист компании Cylance Алекс Матросов (Alex Matrosov) представил доклад, посвященный уязвимостям, которые он обнаружил в имплементациях Intel UEFI BIOS ряда производителей материнских плат. Тогда исследователь рассказал, что найденные им баги позволяют обойти защитные механизмы BIOS, в том числе Intel Boot Guard и Intel BIOS Guard, а также изменить или подменить сам UEFI BIOS, к примеру, внедрив в него руткит.
Протестированные исследователем устройства базировались на популярной среди OEM-производителей AMI Aptio UEFI BIOS (используют Gigabyte, MSI, Asus, Acer, Dell, HP, ASRock и другие). Тогда Матросов рассказал о шести уязвимостях в четырех материнских платах:
Исследователь сетовал, что производители материнских плат не используют аппаратные защитные механизмы, в том числе представленные Intel много лет назад, такие как защитные биты для SMM и SPI (BLE, BWE, PRx). А так как активной защиты памяти на аппаратном уровне нет, устройства этих производителей в теории становятся легкими мишенями для атакующих.
Теперь исследование Матросова продолжил специалист компании Embedi Александр Ермолов. Эксперт обошел защиту Intel Boot Guard на материнский плате Gigabyte GA-H170-D3H, и в процессе выяснил, что проблема, скорее всего, распространяется даже дальше, чем предполагалось изначально.
Ермолов связался с представителями AMI, чтобы уведомить их о проблеме, но ему сообщили, что уязвимости уже были устранены и последняя версия AMI BIOS, доступная для производителей, уже лишена таких недостатков. Когда исследователь решил проверить работу патча, оказалось, что исправление, по сути, лишь ухудшило и без того скверную ситуацию. С полным описанием проблемы можно ознакомиться в блоге Embedi.
Доверенная загрузка Шрёдингера. Intel Boot Guard
Категории
Свежие записи
Наши услуги
Предлагаем вновь спуститься на низкий уровень и поговорить о безопасности прошивок x86-совместимых компьютерных платформ. В этот раз главным ингредиентом исследования является Intel Boot Guard (не путать с Intel BIOS Guard!) – аппаратно-поддержанная технология доверенной загрузки BIOS, которую вендор компьютерной системы может перманентно включить или выключить на этапе производства. Ну а рецепт исследования нам уже знаком: тонко нарезать реверс-инжинирингом имплементацию данной технологии, описать её архитектуру, наполнив недокументированными деталями, приправить по вкусу векторами атак и перемешать. Подбавим огня рассказом о том, как годами клонируемая ошибка на производстве нескольких вендоров позволяет потенциальному злоумышленнику использовать эту технологию для создания в системе неудаляемого (даже программатором) скрытого руткита.
Кстати, в основе статьи – доклады «На страже руткитов: Intel BootGuard» с конференции ZeroNights 2016 и 29-й встречи DefCon Russia (обе презентации здесь ).
Прошивка компьютерной платформы с архитектурой Intel 64
Для начала ответим на вопрос: что является прошивкой современной компьютерной платформы с архитектурой Intel 64? Разумеется, UEFI BIOS. Но такой ответ будет не точным. Давайте взгянем на рисунок, где изображен десктопный (лэптопный) вариант этой архитектуры.
Основой является связка:
Ноутбуки, помимо вышеперечисленного, предполагают наличие встроенного контроллера (ACPI EC, Advanced Control and Power Interface Embedded Controller), который отвечает за работоспособность подсистемы питания, тачпада, клавиатуры, Fn-клавиш (яркость экрана, громкость звука, подсветка клавиатуры и т.п.) и прочего. И у него тоже есть своя прошивка.
Так вот, совокупность вышеперечисленных прошивок и является прошивкой компьютерной платформы (system firmware), которая хранится на общей SPI флэш-памяти. Чтобы пользователи этой памяти не путались, где чьё лежит, содержимое этой памяти разбито на следующие регионы (как показано на рисунке):
Разграничением доступа к регионам (в соответствии с заданными разрешениями) занимается мастер шины SPI – встроенный в чипсет SPI-контроллер, через который и осуществляется обращение к этой памяти. Если разрешения установлены в рекомендуемые (из соображений безопасности) компанией Intel значения, то каждый пользователь SPI флэш-памяти имеет полный доступ (чтение/запись) только к своему региону. А остальные — либо доступны только для чтения, либо недоступны. Известный факт: на многих системах CPU имеет полный доступ к UEFI BIOS и GbE, доступ на чтение только к флэш-дескрипторам, а к региону Intel ME доступа нет вообще. Почему на многих, а не на всех? Что рекомендуемо, то необязательно. Подробнее расскажем далее в статье.
Механизмы защиты прошивки компьютерной платформы от модификации
Очевидно, что прошивку компьютерной платформы следует защищать от возможной компрометации, которая позволила бы потенциальному злоумышленнику закрепиться в ней (переживать обновления/переустановки ОС), исполнять свой код в наиболее привелегированных режимах и т.д. И разграничения доступа к регионам SPI флэш-памяти, разумеется, не достаточно. Поэтому для защиты прошивки от модификаций применяются различные механизмы, специфичные для каждой среды исполения.
А прошивка ACPI EC, как правило, проверяется только на целостность. Однако, ввиду того, что этот бинарь включён в состав UEFI BIOS, на него почти всегда распространяются те же механизмы защиты, что использует UEFI BIOS. О них и поговорим.
Эти механизмы можно разделить на две категории.
Защита от записи в регион UEFI BIOS
В дополнение к этим механизмам, вендоры могут разрабатывать и применять собственные меры безопасности (например, подписывание капсул с обновлениями UEFI BIOS).
Верификация подлинности UEFI BIOS
Когда мы говорим о технологиях доверенной загрузки, первое, что приходит на ум, — Secure Boot. Однако, архитектурно он предназначен для проверки подлинности внешних, по отношению к UEFI BIOS, компонентов (драйверов, загрузчиков и т.д.), а не самой прошивки.
Поэтому компания Intel в SoC-ах с микроархитектурой Bay Trail (2012 год) реализовала аппаратный неотключаемый Secure Boot (Verified Boot), не имеющий ничего общего с вышеупомянутой технологией Secure Boot. Позже (2013 год) этот механизм был усовершенствован и под именем Intel Boot Guard выпущен для десктопов с микроархитектурой Haswell.
Перед описанием Intel Boot Guard разберёмся со средами исполнения в архитектуре Intel 64, которые, по совместительству, являются корнями доверия для этой технологии доверенной загрузки.
Intel CPU
Кэп подсказывает, что процессор является основной средой исполнения в архитектуре Intel 64. Почему он же он является корнем доверия? Оказывается, таковым его делает обладание следующими элементами:
Intel ME
Несмотря на скрытность, Intel ME тоже является корнем доверия, поскольку имеет:
Intel Boot Guard 1.x
Небольшой дисклеймер. Номера версий технологии Intel Boot Guard, которыми мы оперируем в этой статье, являются условными, и могут не иметь ничего общего с нумерацией, которая применяется во внутренней документации компании Intel. К тому же, приведённые здесь сведения об имплементации этой технологии были получены в ходе реверс-инжиниринга, и могут содержать неточности по сравнению со спецификацией на Intel Boot Guard, которая вряд ли когда-нибудь будет опубликована.
Итак, Intel Boot Guard (BG) – аппаратно-поддержанная технология верификации подлинности UEFI BIOS. Судя по её небольшому описанию в книге [Platform Embedded Security Technology Revealed, глава Boot with Integrity, or Not Boot], работает она как цепочка доверенной загрузки. И первое звено в ней — загрузочный код (микрокод) внутри CPU, который запускается по событию RESET (не путать с RESET-вектором в BIOS!). CPU находит на SPI флэш-памяти разработанный и подписанный компанией Intel кодовый модуль (Intel BG startup ACM), загружает к себе в кэш, верифицирует (выше уже было отмечено, что CPU имеет хеш публичного ключа, которым проверяется подпись ACM) и запускает.
Этот кодовый модуль отвечает за верификацию небольшой стартовой части UEFI BIOS — Initial Boot Block (IBB), который, в свою очередь, содержит функциональность для верификации основной части UEFI BIOS. Таким образом, Intel BG позволяет убедиться в подлинности BIOS перед загрузкой ОС (которая может выполняться под наблюдением технологии Secure Boot).
Технология Intel BG предусматривает два режима работы (причём один другому не мешает, т.е. оба режима могут быть включены на системе, а могут быть оба выключены).
Measured Boot
В режиме Measured Boot (MB) каждый загрузочный компонент (начиная с CPU boot ROM) «измеряет» следующий, используя возможности TPM (Trusted Platform Module). Для тех, кто не в курсе, поясним.
У TPM есть PCR-ы (Platform Configuration Registers), в которые записывается результат операции хеширования по формуле:
Т.е. текущее значение PCR зависит от предыдущего, при этом обнуляются данные регистры только при RESET-е системы.
Таким образом, в режиме MB в некоторый момент времени PCR-ы отражают уникальный (в пределах возможностей операции хеширования) идентификатор кода или данных, которые «измерялись». Значения PCR могут быть использованы при операции шифрования некоторых данных (TPM_Seal). После этого, их дешифровка (TPM_Unseal) возможна будет только в случае, если значения PCR в результате загрузки не изменились (т.е. ни один «измеряемый» компонент не был модифицирован).
Verified Boot
Самым страшным для любителей модифицировать UEFI BIOS является режим Verified Boot (VB), при котором каждый загрузочный компонент криптографически проверяет целостность и подлинность следующего. А в случае ошибки верификации, происходит (одно из):
Выбор действия зависит от заданной конфигурации Intel BG (а именно, от т.н. enforcement policy), которая вендором компьютерной платформы перманентно записывается в специально предназначенное хранилище – фьюзы чипсета (FPF-ы). Подробнее на этом моменте остановимся позже.
Помимо конфигурации, вендор генерирует два ключа RSA 2048 и создаёт две структуры данных (изображено на рисунке):
SHA256 хеш публичного ключа OEM Root Key перманентно записывается во фьюзы чипсета (FPF-ы), как и конфигурация Intel BG. Если конфигурация Intel BG предусматривает включение этой технологии, то с этого момента на данной системе обновлять BIOS (т.е. иметь возможность пересчитывать эти манифесты) может только обладатель приватной части OEM Root Key, т.е. вендор.
При взгляде на картинку сразу возникают сомнения в необходимости такой длинной цепочки верификации – можно же было использовать один манифест. Зачем усложнять?
На самом деле компания Intel таким образом предоставляет вендору возможность использовать разные ключи IBB для разных линеек своих продуктов и один – в качестве корневого. Если утечёт приватная часть ключа IBB (которым подписывается второй манифест), инцидент затронет только одну линейку продуктов и только до тех пор, пока вендор не сгенерирует новую пару и не включит пересчитанные манифесты в следующем обновлении BIOS.
Но если будет скомпрометирован корневой ключ (которым подписывается первый манифест), заменить его будет нельзя, процедуры ревокации не предусмотрено т.к. хеш публичной части этого ключа программируется в FPF-ы один раз и навсегда.
Конфигурация Intel Boot Guard
Теперь остановимся подробнее на конфигурации Intel BG и процессе её создания. Если взглянуть на соответствующую вкладку в GUI утилиты Flash Image Tool из комплекта Intel System Tool Kit (STK), можно заметить, что конфигурация Intel BG включает хеш публичной части корневого ключа вендора, пару непонятных значений и т.н. профиль Intel BG.
Структура этого профиля:
Вообще, конфигурация Intel BG – сущность очень гибкая. Рассмотрим, например, флаг Force_Boot_Guard_ACM. Когда он снят, в случае, если модуль BG startup ACM на SPI флэш-памяти не будет найден, никакой доверенной загрузки не будет. Будет недоверенная.
Выше мы уже писали, что enforcement policy для режима VB можно настроить так, что при ошибке верификации произойдет, опять же, недоверенная загрузка.
Оставлять такие вещи на усмотрение вендоров…
GUI утилиты предусматривает следующие «готовые» профили:
Номер
Режим
Описание
0
No_FVME
технология Intel BG выключена
1
VE
включён режим VB, выключение по таймауту
2
VME
включены оба режима (VB и MB), выключение по таймауту
3
VM
включены оба режима, без выключения системы
4
FVE
включён режим VB, немедленное выключение
5
FVME
включены оба режима, немедленное выключение
Как уже было сказано, конфигурация Intel BG должна быть раз и навсегда записана вендором системы во фьюзы чипсета (FPF-ы) – небольшое (по непроверенным сведениям, всего 256 байт) аппаратное хранилище информации внутри чипсета, которое может быть запрограммировано вне производственных мощностей компании Intel (поэтому, именно Field Programmable Fuses).
Оно отлично подходит для хранения конфигурации, поскольку:
Итак, для того, чтобы задать конфигурацию для технологии Intel BG на конкретной системе, вендор во время производства делает следующее:
В результате этих операций, Intel ME скоммитит в FPF-ы заданные значения из зеркала для FPF-ов в ME регионе, выставит разрешения в SPI флэш-дескрипторах в рекомендованные компанией Intel значения (описывалось в начале статьи) и выполнит RESET системы.
Анализ имплементации Intel Boot Guard
С целью анализа реализации этой технологии на конкретном примере мы проверили следующие системы на предмет наличия следов технологии Intel BG:
Gigabyte GA-H170-D3H
Skylake, есть поддержка
Gigabyte GA-Q170-D3H
Skylake, есть поддержка
Gigabyte GA-B150-HD3
Skylake, есть поддержка
MSI H170A Gaming Pro
Skylake, нет поддержки
Lenovo ThinkPad 460
Skylake, есть поддержка, технология включена
Lenovo Yoga 2 Pro
Haswell, нет поддержки
Lenovo U330p
Haswell, нет поддержки
Под «поддержкой» понимается наличие Intel BG startup ACM модуля, упомянутых выше манифестов и соответствующего кода в BIOS, т.е. имплементации для анализа.
В качестве примера, возьмём скаченный с оф. сайта вендора образ SPI флэш-памяти для Gigabyte GA-H170-D3H (версия F4).
Intel CPU boot ROM
В первую очередь, поговорим о действиях процессора в случае, если технология Intel BG включена.
Образцов дешифрованного микрокода найти не удалось, поэтому то, как описываемые далее действия реализованы (в микрокоде или аппаратно) – вопрос открытый. Тем не менее, то, что современные процессоры Intel «умеют» производить эти действия – факт.
После выхода из состояния RESET процессор (в адресное пространство которого уже смаплено содержимое флэш-памяти) находит таблицу FIT (Firmware Interface Table). Найти её просто, указатель на неё записан по адресу FFFF FFC0h.
В рассматриваемом примере, по этому адресу лежит значение FFD6 9500h. Обратившись по этому адресу, процессор видит таблицу FIT, содержимое которой разбито на записи. Первая запись – заголовок следующей структуры:
По неизвестной причине чексумма далеко не всегда в этих таблицах посчитана (поле оставлено нулевым).
Остальные записи указывают на различные бинари, которые необходимо пропарсить/исполнить ещё до исполнения BIOS, т.е. до перехода на legacy RESET-вектор (FFFF FFF0h). Структура каждой такой записи такова:
Поле EntryType говорит о типе блока, на который указывает эта запись. Нам известно несколько типов:
Теперь очевидно, что одна из записей указывает на местоположение бинаря Intel BG startup ACM. Структура заголовка этого бинаря типична для разрабываемых компанией Intel кодовых модулей (ACM-ы, обновления микрокода, кодовые разделы Intel ME, …).
Процессор загружает этот бинарь к себе в кэш, верифицирует и запускает.
Intel BG startup ACM
В результате анализа работы этого ACM стало ясно, что он делает следующее:
Для нахождения этих манифестов ACM тоже пользуется таблицей FIT, в которой отведено два типа записей для указания на данные структуры (см. FIT_ENTRY_TYPES выше).
Остановимся подробнее на манифестах. В структуре первого манифеста мы видим несколько неясных констант, хеш публичного ключа из второго манифеста и публичный ключ OEM Root Key с подписью в виде вложенной структуры:
Для верификации публичного ключа OEM Root Key, напомним, используется SHA256 хеш из фьюзов, который на этот момент уже получен от Intel ME.
Перейдём ко второму манифесту. Он состоит из трёх структур:
В первой – какие-то константы:
Во второй находится SHA256 хеш IBB и число дескрипторов, которые описывают содержимое IBB (т.е. то, от чего считается хеш):
Дескрипторы IBB следуют за этой структурой, один за другим. Их содержимое имеет следующий формат:
Всё просто: каждый дескриптор содержит адрес/размер куска IBB. Таким образом, конкатенация блоков, на которые указывают эти дескрипторы (в порядке расположения самих дескрипторов) и является IBB. И, как правило, IBB — это совокупность всех модулей фаз SEC и PEI.
Второй манифест завершает структура, содержащая публичный ключ IBB (верифицируется SHA256 хеш-ем из первого манифеста) и подпись этого манифеста:
Итак, ещё до начала исполнения UEFI BIOS процессор запустит ACM, который проверит подлинность содержимого разделов с кодом фаз SEC и PEI. Далее, процессор выходит из ACM, переходит по RESET-вектору и начинает исполнять BIOS.
Верифицированный PEI раздел должен содержать модуль, который проверит оставшуюся часть BIOS (DXE код). Этот модуль разрабатывает уже IBV (Independent BIOS Vendor) или сам вендор системы. Т.к. оказавшихся в нашем распоряжении и имеющих поддержку Intel BG оказались только системы Lenovo и Gigabyte, рассмотрим код, извлечённых именно из этих систем.
UEFI BIOS модуль LenovoVerifiedBootPei
В случае с Lenovo, это оказался модуль LenovoVerifiedBootPei
Его работа заключается в поиске (по GUID) хеш-таблицы для DXE и верификации DXE.
UEFI BIOS модуль BootGuardPei
В случае с Gigabyte, это оказался модуль BootGuardPei
Его алгоритм работы несколько иной, однако, сводится к тому же:
Хеш таблица <389CC6F2-1EA8-467B-AB8A-78E769AE2A15>, которую он ищет, имеет следующий формат:
Intel Boot Guard 2.x
Кратко расскажем ещё об одной реализации Intel Boot Guard, которая была найдена в более новой системе на основе Intel SoC с микроархитектурой Apollo Lake — ASRock J4205-IT.
Хотя эта версия будет применяться лишь в SoC-ах (новые системы с процессорной микроархитектурой Kaby Lake продолжают использовать Intel Boot Guard 1.x), она представляет большой интерес в изучении нового варианта архитектуры для платформ на Intel SoC, в которой произошли ощутимые изменения, например:
Содержимое нового региона IFWI представляет собой набор следующих модулей:
Смещение
Имя
Описание
0000 2000h
SMIP
некая конфигурация платформы, подписано вендором
0000 6000h
RBEP
кодовый раздел прошивки Intel TXE, x86, подписано Intel
0001 0000h
PMCP
кодовый раздел прошивки Intel PMC, ARC, подписано Intel
0002 0000h
FTPR
кодовый раздел прошивки Intel TXE, x86, подписано Intel
0007 B000h
UCOD
обновления микрокода для CPU, подписано Intel
0008 0000h
IBBP
UEFI BIOS, фазы SEC/PEI, x86, подписано вендором
0021 8000h
ISHC
кодовый раздел прошивки Intel ISH, x86, подписано вендором
0025 8000h
NFTP
кодовый раздел прошивки Intel TXE, x86, подписано Intel
0036 1000h
IUNP
неизвестно
0038 1000h
OBBP
UEFI BIOS, фаза DXE, x86, не подписано
В ходе анализа прошивки TXE стало очевидно, что после RESET-а TXE держит процессор в этом состоянии до тех пор, пока не подготовит базовое содержимое адресного пространства для CPU (FIT, ACM, RESET-вектор …). Причём TXE размещает эти данные у себя в SRAM, после чего временно предоставляет процессору туда доступ и «отпускает» его из RESET-а.
На страже руткитов
Ну а теперь перейдём к «горячему». Однажды мы обнаружили, что на многих системах в SPI флэш-дескрипторах записаны разрешения на доступ к регионам SPI флэш-памяти так, что все пользователи этой памяти могут и писать, и читать любой регион. Т.е. никак.
После проверки с помощью утилиты MEinfo (из Intel STK) мы увидели, что manufacturing mode на этих системах не закрыт, следовательно, фьюзы чипсета (FPF-ы) оставлены в неопределённом состоянии. Да, Intel BG в таких случаях ни включён, ни выключен.
Речь идёт о следующих системах (касаемо Intel BG и того, что будет изложено далее в статье, мы будем говорить о системах с процессорной микроархитектурой Haswell и выше):
Разумеется, мы сообщили о находке этим вендорам, а также компании Intel.
Gigabyte вроде и приняли информацию об уязвимости, но никак не прокомментировали.
Общение с MSI вовсе застопорилось на нашей просьбе прислать свой открытый PGP-ключ (чтобы отправить им security advisory в зашифрованном виде). Они заявили, что «являются производителем оборудования, и PGP-ключи не производят».
Но ближе к делу. Поскольку фьюзы оставлены в незаданном состоянии, пользователь (или злоумышленник) может их запрограммировать самостоятельно (самое сложное — найти Intel STK ). Для этого требуется выполнить следующие действия.
1. Загрузиться в ОС Windows (вообще, описываемые далее действия можно сделать и из под Linux, если разработать аналог Intel STK под нужную ОС). Используя утилиту MEinfo, убедиться в том, что фьюзы на данной системе не запрограммированы.
2. Считать содержимое флэш-памяти при помощи Flash Programming Tool.
3. Открыть считанный образ при помощи любого средства для редактирования UEFI BIOS, внести необходимые изменения (внедрить руткит, например), создать/отредактировать имеющиеся структуры KEYM и IBBM в ME регионе.
На картинке выделена публичная часть ключа RSA, хеш которой будет запрограммирован во фьюзы чипсета вместе остальной конфигурацией Intel BG.
4. При помощи Flash Image Tool собрать новый образ прошивки (задав конфигурацию Intel BG).
5. Записать новый образ на флэш-память при помощи Flash Programming Tool, убедиться при помощи MEinfo, что ME регион теперь содержит конфигурацию Intel BG.
6. При помощи Flash Programming Tool закрыть режим manufacturing mode.
7. Система перезазгрузится, после чего при помощи MEinfo можно убедиться в том, что FPF-ы теперь запрограммированы.
Эти действия навсегда включат Intel BG на данной системе. Отменить действие будет нельзя, что означает:
Для понимания того, что может натворить такой руткит, нужно оценить, что даёт возможность исполнять свой код в среде UEFI BIOS. Скажем, в самом привилегированном режиме процессора – SMM. Такой руткит может иметь следующие свойства:
Таким образом, эта уязвимость позволяет злоумышленнику:
Хотя возможности подсистемы Intel ISH ещё не изучены, она представляется интересным вектором атаки на Intel ME.
Выводы
Mitigations
Вендорам, которые намеренно оставляют manufacturing mode открытым, следует его обязательно закрывать. Пока что закрывают только глаза и новые Kaby Lake системы это показывают.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
