Доверенная загрузка Шрёдингера. Intel Boot Guard / forpes.ru

Главная
Доверенная загрузка Шрёдингера. Intel Boot Guard

Доверенная загрузка Шрёдингера. Intel Boot Guard +57

18.04.2017 06:27

flothrone 29 12200 Источник

Предлагаем вновь спуститься на низкий уровень и поговорить о безопасности прошивок x86-совместимых компьютерных платформ. В этот раз главным ингредиентом исследования является Intel Boot Guard (не путать с Intel BIOS Guard!) – аппаратно-поддержанная технология доверенной загрузки BIOS, которую вендор компьютерной системы может перманентно включить или выключить на этапе производства. Ну а рецепт исследования нам уже знаком: тонко нарезать реверс-инжинирингом имплементацию данной технологии, описать её архитектуру, наполнив недокументированными деталями, приправить по вкусу векторами атак и перемешать. Подбавим огня рассказом о том, как годами клонируемая ошибка на производстве нескольких вендоров позволяет потенциальному злоумышленнику использовать эту технологию для создания в системе неудаляемого (даже программатором) скрытого руткита.

Кстати, в основе статьи – доклады «На страже руткитов: Intel BootGuard» с конференции ZeroNights 2016 и 29-й встречи DefCon Russia (обе презентации здесь).

Прошивка компьютерной платформы с архитектурой Intel 64

Для начала ответим на вопрос: что является прошивкой современной компьютерной платформы с архитектурой Intel 64? Разумеется, UEFI BIOS. Но такой ответ будет не точным. Давайте взгянем на рисунок, где изображен десктопный (лэптопный) вариант этой архитектуры.

Основой является связка:

Процессора (CPU, Central Processing Unit), в который, помимо основных ядер, встроено графическое ядро (не во всех моделях) и внедрён контроллер памяти (IMC, Integrated Memory Controller);
Чипсета (PCH, Platform Controller Hub), содержащего различные контроллеры для взаимодействия с периферийными устройствами и управления подсистемами. Среди них — небезызвестная Intel Management Engine (ME), у которой тоже есть прошивка (Intel ME firmware).

Ноутбуки, помимо вышеперечисленного, предполагают наличие встроенного контроллера (ACPI EC, Advanced Control and Power Interface Embedded Controller), который отвечает за работоспособность подсистемы питания, тачпада, клавиатуры, Fn-клавиш (яркость экрана, громкость звука, подсветка клавиатуры и т.п.) и прочего. И у него тоже есть своя прошивка.

Так вот, совокупность вышеперечисленных прошивок и является прошивкой компьютерной платформы (system firmware), которая хранится на общей SPI флэш-памяти. Чтобы пользователи этой памяти не путались, где чьё лежит, содержимое этой памяти разбито на следующие регионы (как показано на рисунке):

UEFI BIOS;
прошивка ACPI EC (отдельный регион появился с процессорной микроархитектуры Skylake (2015 год), но in-the-wild мы пока не видели примеров его использования, так что прошивка встроенного контроллера по-прежнему входит в состав UEFI BIOS);
прошивка Intel ME;
конфигурация (MAC-адрес и т.д.) встроенного сетевого адаптера GbE (Gigabit Ethernet);
флэш-дескрипторы (Flash Descriptors) – главный регион флэш-памяти, который содержит указатели на остальные регионы, а также разрешения на доступ к ним.

Разграничением доступа к регионам (в соответствии с заданными разрешениями) занимается мастер шины SPI – встроенный в чипсет SPI-контроллер, через который и осуществляется обращение к этой памяти. Если разрешения установлены в рекомендуемые (из соображений безопасности) компанией Intel значения, то каждый пользователь SPI флэш-памяти имеет полный доступ (чтение/запись) только к своему региону. А остальные — либо доступны только для чтения, либо недоступны. Известный факт: на многих системах CPU имеет полный доступ к UEFI BIOS и GbE, доступ на чтение только к флэш-дескрипторам, а к региону Intel ME доступа нет вообще. Почему на многих, а не на всех? Что рекомендуемо, то необязательно. Подробнее расскажем далее в статье.

Механизмы защиты прошивки компьютерной платформы от модификации

Очевидно, что прошивку компьютерной платформы следует защищать от возможной компрометации, которая позволила бы потенциальному злоумышленнику закрепиться в ней (переживать обновления/переустановки ОС), исполнять свой код в наиболее привелегированных режимах и т.д. И разграничения доступа к регионам SPI флэш-памяти, разумеется, не достаточно. Поэтому для защиты прошивки от модификаций применяются различные механизмы, специфичные для каждой среды исполения.

Так, прошивка Intel ME подписана для контроля целостности и подлинности, и проверяется ME-контроллером при каждой её загрузке в память ME UMA. Этот процесс верификации уже рассматривался нами в одной из статей, посвящённой подсистеме Intel ME.

А прошивка ACPI EC, как правило, проверяется только на целостность. Однако, ввиду того, что этот бинарь включён в состав UEFI BIOS, на него почти всегда распространяются те же механизмы защиты, что использует UEFI BIOS. О них и поговорим.

Эти механизмы можно разделить на две категории.

Защита от записи в регион UEFI BIOS

Физическая защита содержимого SPI флэш-памяти write-protect джампером;
Защита проекции региона UEFI BIOS в адресном пространстве CPU с помощью PRx регистров чипсета;
Блокировка попыток записи в регион UEFI BIOS генерацией и обработкой соответствующего прерывания SMI путём выставления битов BIOS_WE/BLE и SMM_BWP в регистрах чипсета;
Более продвинутый вариант такой защиты – Intel BIOS Guard (PFAT).

В дополнение к этим механизмам, вендоры могут разрабатывать и применять собственные меры безопасности (например, подписывание капсул с обновлениями UEFI BIOS).

Важно отметить, что на конкретной системе (зависит от вендора) могут быть применены не все вышеперечисленные механизмы защиты, могут быть вообще не применены, а могут быть уязвимо реализованы. Подробнее об этих механизмах и о ситуации с их реализацией можно почитать в этой статье. Интересующимся рекомендуем ознакомиться со всем циклом статей по безопасности UEFI BIOS от CodeRush.

Верификация подлинности 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. Почему он же он является корнем доверия? Оказывается, таковым его делает обладание следующими элементами:

Microcode ROM — энергонезависимая, неперезаписываемая память для хранения микрокода. Считается, что микрокодом является имплементация системы команд процессора на простейших инструкциях. В микрокоде тоже случаются баги. Так что в BIOS можно найти бинари с обновлениями микрокода (накладываются во время загрузки, т.к. ROM нельзя перезаписать). Содержимое этих бинарей зашифровано, что значительно усложняет анализ (поэтому, конкретное содержание микрокода известно только тем, кто его разрабатывает), и подписано, для контроля целостности и подлинности;
AES ключ для дешифровки содержимого обновлений микрокода;
хеш публичного ключа RSA, которым проверяется подпись обновлений микрокода;
хеш публичного ключа RSA, которым проверяется подпись разработанных компанией Intel кодовых модулей ACM (Authenticated Code Module), которые CPU может запускать до начала исполнения BIOS (привет микрокоду) или во время его работы, при возникновении некоторых событий.

Intel ME

Данной подсистеме в нашем блоге было посвящено аж две статьи. Напомним, что эта исполнимая среда основана на встроенном в чипсет микроконтроллере и является самой скрытой и привилегированной в системе.

Несмотря на скрытность, Intel ME тоже является корнем доверия, поскольку имеет:

ME ROM — энергонезависимую, неперезаписываемую память (способа обновления не предусмотрено), содержащую стартовый код, а также SHA256 хеш публичного ключа RSA, которым проверяется подпись прошивки Intel ME;
AES ключ для хранения секретной информации;
доступ к интегрированному в чипсет набору фьюзов (FPFs, Field Programmable Fuses) для перманентного хранения некоторой информации, в том числе, и заданной вендором компьютерной системы.

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), в которые записывается результат операции хеширования по формуле:

$display$

Т.е. текущее значение PCR зависит от предыдущего, при этом обнуляются данные регистры только при RESET-е системы.

Таким образом, в режиме MB в некоторый момент времени PCR-ы отражают уникальный (в пределах возможностей операции хеширования) идентификатор кода или данных, которые «измерялись». Значения PCR могут быть использованы при операции шифрования некоторых данных (TPM_Seal). После этого, их дешифровка (TPM_Unseal) возможна будет только в случае, если значения PCR в результате загрузки не изменились (т.е. ни один «измеряемый» компонент не был модифицирован).

Verified Boot

Самым страшным для любителей модифицировать UEFI BIOS является режим Verified Boot (VB), при котором каждый загрузочный компонент криптографически проверяет целостность и подлинность следующего. А в случае ошибки верификации, происходит (одно из):

выключение по таймауту от 1 мин до 30 мин (чтобы пользователь успел понять, по какой причине у него компьютер не грузится, и, по возможности, попытался бы восстановить BIOS);
немедленное выключение (чтобы пользователь ничего не успел понять и, тем более, сделать);
продолжение работы с невозмутимым видом (тот случай когда не до безопасности, ведь есть дела поважнее).

Выбор действия зависит от заданной конфигурации Intel BG (а именно, от т.н. enforcement policy), которая вендором компьютерной платформы перманентно записывается в специально предназначенное хранилище – фьюзы чипсета (FPF-ы). Подробнее на этом моменте остановимся позже.

Помимо конфигурации, вендор генерирует два ключа RSA 2048 и создаёт две структуры данных (изображено на рисунке):

Манифест корневого ключа вендора (KEYM, OEM Root Key Manifest), в который кладёт SVN (Security Version Number) этого манифеста, SHA256 хеш публичного ключа следующего манифеста, публичный ключ RSA (т.е. публичную часть корневого ключа вендора) для проверки подписи этого манифеста и саму подпись;
Манифест IBB (IBBM, Initial Boot Block Manifest), в который кладёт SVN этого манифеста, SHA256 хеш IBB, публичный ключ для проверки подписи этого манифеста и саму подпись.

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.

Структура этого профиля:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

Вообще, конфигурация 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).

Оно отлично подходит для хранения конфигурации, поскольку:

имеет one-time-programmable область для хранения данных (как раз туда, куда записывается конфигурация Intel BG);
читать и программировать его может только Intel ME.

Итак, для того, чтобы задать конфигурацию для технологии Intel BG на конкретной системе, вендор во время производства делает следующее:

С помощью утилиты Flash Image Tool (из Intel STK) создаёт образ прошивки с заданной конфигурацией Intel BG в виде переменных внутри региона Intel ME (т.н. временное зеркало для FPF-ов);
С помощью утилиты Flash Programming Tool (из Intel STK) записывает этот образ на SPI флэш-память системы и закрывает т.н. manufacturing mode (при этом, производится отправка соответствующей команды в Intel ME).

В результате этих операций, 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, содержимое которой разбито на записи. Первая запись – заголовок следующей структуры:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

По неизвестной причине чексумма далеко не всегда в этих таблицах посчитана (поле оставлено нулевым).

Остальные записи указывают на различные бинари, которые необходимо пропарсить/исполнить ещё до исполнения BIOS, т.е. до перехода на legacy RESET-вектор (FFFF FFF0h). Структура каждой такой записи такова:

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

Поле EntryType говорит о типе блока, на который указывает эта запись. Нам известно несколько типов:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

Теперь очевидно, что одна из записей указывает на местоположение бинаря Intel BG startup ACM. Структура заголовка этого бинаря типична для разрабываемых компанией Intel кодовых модулей (ACM-ы, обновления микрокода, кодовые разделы Intel ME, ...).

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

Процессор загружает этот бинарь к себе в кэш, верифицирует и запускает.

Intel BG startup ACM

В результате анализа работы этого ACM стало ясно, что он делает следующее:

получает от Intel ME конфигурацию Intel BG, записанную во фьюзы чипсета (FPF-ы);
находит манифесты KEYM и IBBM, верифицирует их.

Для нахождения этих манифестов ACM тоже пользуется таблицей FIT, в которой отведено два типа записей для указания на данные структуры (см. FIT_ENTRY_TYPES выше).

Остановимся подробнее на манифестах. В структуре первого манифеста мы видим несколько неясных констант, хеш публичного ключа из второго манифеста и публичный ключ OEM Root Key с подписью в виде вложенной структуры:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

Для верификации публичного ключа OEM Root Key, напомним, используется SHA256 хеш из фьюзов, который на этот момент уже получен от Intel ME.

Перейдём ко второму манифесту. Он состоит из трёх структур:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

В первой – какие-то константы:

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

Во второй находится SHA256 хеш IBB и число дескрипторов, которые описывают содержимое IBB (т.е. то, от чего считается хеш):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

Дескрипторы IBB следуют за этой структурой, один за другим. Их содержимое имеет следующий формат:

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

Всё просто: каждый дескриптор содержит адрес/размер куска IBB. Таким образом, конкатенация блоков, на которые указывают эти дескрипторы (в порядке расположения самих дескрипторов) и является IBB. И, как правило, IBB — это совокупность всех модулей фаз SEC и PEI.

Второй манифест завершает структура, содержащая публичный ключ IBB (верифицируется SHA256 хеш-ем из первого манифеста) и подпись этого манифеста:

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

Итак, ещё до начала исполнения UEFI BIOS процессор запустит ACM, который проверит подлинность содержимого разделов с кодом фаз SEC и PEI. Далее, процессор выходит из ACM, переходит по RESET-вектору и начинает исполнять BIOS.

Верифицированный PEI раздел должен содержать модуль, который проверит оставшуюся часть BIOS (DXE код). Этот модуль разрабатывает уже IBV (Independent BIOS Vendor) или сам вендор системы. Т.к. оказавшихся в нашем распоряжении и имеющих поддержку Intel BG оказались только системы Lenovo и Gigabyte, рассмотрим код, извлечённых именно из этих систем.

UEFI BIOS модуль LenovoVerifiedBootPei

В случае с Lenovo, это оказался модуль LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}, разработанный компанией Lenovo.

Его работа заключается в поиске (по GUID) хеш-таблицы для DXE и верификации DXE.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS модуль BootGuardPei

В случае с Gigabyte, это оказался модуль BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}, разработанный компанией AMI, следовательно, присутствующий в любом AMI BIOS с поддержкой Intel BG.

Его алгоритм работы несколько иной, однако, сводится к тому же:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15}, которую он ищет, имеет следующий формат:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

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, в которой произошли ощутимые изменения, например:

регионы BIOS и Intel ME (вернее Intel TXE, согласно терминологии для Intel SoC) теперь являются одним регионом IFWI;
хоть на платформе был включён Intel BG, таких структур, как FIT, KEYM, IBBM не было найдено во флэш-памяти;
помимо TXE и ISH ядер (x86), в чипсет добавили третье ядро (снова ARC, кстати) – PMC (Power Management Controller), связанный с обеспечением работоспособности подсистемы питания и мониторингом производительности.

Содержимое нового региона 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 и выше):

вся продукция Gigabyte;
вся продукция MSI;
21 модель ноутбуков Lenovo и 4 модели серверов Lenovo.

Разумеется, мы сообщили о находке этим вендорам, а также компании Intel.

Адекватная реакция последовала только от Lenovo, которые признали проблему и выпустили патч.

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 на данной системе сможет только обладатель приватной части корневого ключа (т.е. тот, кто включил Intel BG);
если вернуть этой системе оригинальную прошивку, например, с помощью программатора, она даже не включится (следствие enforcement policy в случае ошибки верификации);
чтобы избавиться от такого UEFI BIOS, требуется заменить чипсет с запрограммированными FPF-ами на «чистый» (т.е. перепаять чипсет, если у вас есть доступ к инфракрасной паяльной станции ценой в автомобиль, ну или просто заменить материнскую плату).

Для понимания того, что может натворить такой руткит, нужно оценить, что даёт возможность исполнять свой код в среде UEFI BIOS. Скажем, в самом привилегированном режиме процессора – SMM. Такой руткит может иметь следующие свойства:

исполняться параллельно ОС (можно настроить отработку по генерации SMI прерывания, которое будет триггериться по таймеру);
иметь все преимущества нахождения в режиме SMM (полный доступ к содержимому оперативной памяти и к аппаратным ресурсам, скрытность от ОС);
программный код руткита может находиться в шифрованном виде и дешифровываться при запуске в режиме SMM. В качестве ключа для шифрования можно использовать любые данные, доступные только в режиме SMM. Например, хеш от набора адресов в SMRAM. Чтобы получить этот ключ, потребуется забраться в SMM. А это можно сделать двумя способами. Найти RCE в коде SMM и проэксплуатировать, либо добавить в BIOS свой SMM модуль, что невозможно, поскольку мы включили Boot Guard.

Таким образом, эта уязвимость позволяет злоумышленнику:

создать в системе скрытый, неудаляемый руткит неизвестного назначения;
исполнять свой код на одном из ядер чипсета внутри Intel SoC, а именно, на Intel ISH (внимательно взглянем на картинку).

Хотя возможности подсистемы Intel ISH ещё не изучены, она представляется интересным вектором атаки на Intel ME.

Выводы

Исследование позволило получить техническое описание работы технологии Intel Boot Guard. Минус пара тайн в Intel-овской модели security through obscurity.
Представлен сценарий атаки, позволяющий создать в системе неудаляемый руткит.
Мы увидели, что современные процессоры Intel способны исполнить много проприетарного кода ещё до начала работы BIOS.
Платформы с архитектурой Intel 64 становятся всё менее пригодными для запуска свободного ПО: аппаратная верификация, увеличивающееся число проприетарных технологий и подсистем (три ядра в чипсете SoC: x86 ME, x86 ISH и ARC PMC).

Mitigations

Вендорам, которые намеренно оставляют manufacturing mode открытым, следует его обязательно закрывать. Пока что закрывают только глаза и новые Kaby Lake системы это показывают.

Пользователи могут сами выключить Intel BG у себя на системах (которые подвержены описанной уязвимости), запустив утилиту Flash Programming Tool с параметром -closemnf. Предварительно, следует убедиться (при помощи MEinfo), что конфигурация Intel BG в регионе ME предусматривает именно выключение этой технологии после программирования в FPF-ы.

Поделиться с друзьями

-->

Комментарии (29)

orcy
18.04.2017 11:53
#10178128
+1
Довольно интересно было почитать как все это устроенно.

> Платформы с архитектурой Intel 64 становятся всё менее пригодными для запуска свободного ПО
Это конечно не очень радует

Cobolorum
18.04.2017 13:11
#10178372
+4
А еще 15 лет назад все это нагромождение технологий заменял один джампер- FlashWriteProtect. И все работало и работает до сих пор.
1. unet900
  18.04.2017 13:25
  #10178400
  О как вы правы! Полагаю мы к этому еще вернемся. Будет новая маркетинговая фишка сезона)
1. lorc
  18.04.2017 13:32
  #10178418
  +1
  Не всегда, надо заметить. Если в ноутбук еще можно поставить джампер (хоть это будет и неудобно), то в в планшет или смартфон — чаще всего нельзя совсем.
  Или другой кейс: вы — техдиректор небольшой компании на десять тысяч человек. И всем нужно срочно обновить биос. Вы лично пойдете переставлять джампера по всем филиалам? Есть и другие кейсы…
  Интел выбрали правильный подход. И реализовали более-менее грамотно. Проблема как обычно в вендорах, которые не соблюдают рекомендации.
  1. khim
    18.04.2017 16:56
    #10179124
    Если в ноутбук еще можно поставить джампер (хоть это будет и неудобно), то в в планшет или смартфон — чаще всего нельзя совсем.
    Неудобно производителю. Потому что он после этого не может творить с купленной вами железкой чего захоется в любое удобное для него (а не для вас!) время.
    
    Планшетов или смартфором размером с SD-карту (где джампер был) я не видел, так что всё упирается совсем не в то, что тут какие-то технологические проблемы…
    
    lorc
    18.04.2017 17:30
    #10179198
    +1
    Неудобно производителю, неудобно пользователю. Вообще давайте подумаем: от чего защищает джампер? От записи в ненужный момент. Но он не защитит от записи не того, например. Т.е. если мы убедим пользователя поставить джампер в нужное положение, то можно зашивать туда что угодно. В то время как криптографическая подпись позволит гарантировать что будет записана именно то, что надо. Просто криптография хороша только тогда, когда ею пользуются правильно. А вендоры не захотели делать это правильно, поэтому теперь у них проблемы. Но точно так же вендоры могли закоротить джампер прямо на заводе. Эффект был бы тот же.
    Короче, не в джамперах проблема. А в кривых руках и непрофессионализме.
    
    А то что вы не владеете купленным вами железом — это конечно проблема. Для вас. Потому что большинство остальных это устраивает. Если бы это не устраивало пользователей — они бы не покупали это железо. Обычному пользователю неинтересно ковыряться в этих ваших UEFI и сравнивать глазами SHA256 хеш скачанной прошивки с хешем на сайте производителя. Они хотят что бы всё происходило автомагически. И производители дают им эту возможность.
    
    Но к счастью у вас есть возможность покупать девелоперские железки, где всё (или почти всё) разлоченно, и можно делать с ними что угодно. Хакеры всех эпох всегда оставались на обочине консьюмерского рынка. Это совершенно нормально.
    
    sumanai
    18.04.2017 17:49
    #10179260
    +1
    В то время как криптографическая подпись позволит гарантировать что будет записана именно то, что надо.
    
    Именно. Только то, что нужно вендору. Желания пользователя тут вообще в расчёт не берутся.
    
    Но к счастью у вас есть возможность покупать девелоперские железки
    
    Производительность на нуле. Где найти девелоперский набор на Intel i7? И как это потом запихать в корпус ноутбука?
    
    lorc
    18.04.2017 18:17
    #10179344
    +1
    Именно. Только то, что нужно вендору. Желания пользователя тут вообще в расчёт не берутся.
    
    Почему же не берутся? Пользователю хочется что бы оно всё происходило само. Чем меньше пользователю надо думать — тем лучше. Производители именно это и дают пользователю.
    Судя по тому, что вам нужен полный контроль над процессом — вы не обычный пользователь. Но, к счастью, на данном этапе развития консьюмерской электроники у вас ещё есть возможность контролировать свои устройства. Просто для этого надо знать чуть больше, чем обычный пользователь. Но опять же, если у вас есть потребность — значит есть и знания. Поэтому всё пока не так страшно.
    
    Производительность на нуле. Где найти девелоперский набор на Intel i7? И как это потом запихать в корпус ноутбука?
    
    Можете купить MSI-йный ноутбук :) Судо по этом посту — там разлоченно вообще всё. Твори — не хочу.
    
    Смотрите, я понимаю вашу позицию. И даже поддерживаю её. Просто я хочу донести простую мысль: мы с вами — не целевая аудитория HP, DELL, Asus. Lenovo, Xiaomi и Apple. Для них — мы маргиналы, хотящие странного. Глупо требовать от них открытости и прочих хакерских ценностей. Этого не надо основной массе их клиентов Надо уметь приспосабливать то что есть для своих нужд.
    
    Было классно, если бы существовал дешевый и мощный компьютер на открытой платформе, которую поддерживает Open Source Community и для которой есть тонны хорошого, надежного и удобного софта. Звучит фантастически, не так ли? :)
    
    sumanai
    18.04.2017 20:10
    #10179596
    +1
    Пользователю хочется что бы оно всё происходило само.
    
    Уверены? Как по мне, так ему хочется, чтобы само ничего не происходило. И чтобы вообще ничего лишнего не происходило, и кнопочки всегда были на привычных им местах.
    Ах да, автообновление биоса я всё равно нигде не видел, везде как минимум нужно зайти в него и нажать «Обновить из интернета».
    
    Можете купить MSI-йный ноутбук :) Судо по этом посту — там разлоченно вообще всё. Твори — не хочу.
    
    Intel Management Engine не отключается нигде, по крайней мере без последствий в работоспособности.
1. CodeRush
  18.04.2017 14:34
  #10178632
  +5
  Это не совсем правда, потому что на современной микросхеме SPI хранится сразу несколько прошивок и управляют ей сразу несколько мастеров, каждый из которых хранит в своем регионе изменяющиеся во время загрузки и нормально работы данные, и если всю микросхему разом защитить от записи джампером, то все эти модифицируемые данные придется выносить в CMOS SRAM (15 лет назад именно там они и хранились), к которой очень просто получить доступ через CPU IO-порты 70h/71h или 74h/75h и у которой никаких защитных механизмов нет, а сама она в заметных объемах (256Кб, которые сейчас используют большая часть реализаций UEFI, а ведь есть еще ME, GbE и EC) стоит как самолет.
  Можено попробовать разнести модифицируемые часто и модифицируемые только при обновлении данные по разным SPI-микросхемам и защитить «джампером» последнюю, но это удорожает производство и разработку платы и прошивки, поэтому массовый рынок этим не заморачивается и, скорее всего, никогда не будет.
  1. flothrone
    18.04.2017 16:40
    #10179074
    +2
    Абсолютно согласен.
    Да, WP-джампер сейчас применяется (путём разнесения модифицируемых и немодифицируемых участков прошивки) редко где. Я слышал только о некоторых моделях систем Dell.

CodeRush
18.04.2017 14:16
#10178584
+5
Отличная статья и очень полезный реверс, теперь можно добавить разбор манифестов в UEFITool, не боясь праведного гнева Intel. По поводу контрольной суммы записей в FIT — ей управляет верхний бит Type, а считается она вот так.
В качестве продолжения предлагаю рассмотреть побольше реализаций цепочки доверия, включив Dell и HP, которые давно и относительно успешно занимаются безопасностью своих прошивок, плюс рассмотреть атаки на компоненты самой цепочки безотносительно BootGuard, который защищает только SEC и PEI.
1. flothrone
  18.04.2017 16:54
  #10179110
  +4
  Благодарю.
  Фоном занимаюсь как раз изучением механизмов верификации прошивки в системах Dell. Так что, вероятно, сделаю в будущем материал по теме.

Ivan_83
19.04.2017 00:43
#10179972
-4
Проблема доверенной загрузки высосана из пальца целиком и полностью всякими копирастами и шизанутыми безопасниками.

На практике идеальным решением был rom/flash + CMOS. Долговечно, надёжно, ремонтопригодно.
Всё что было на диске — это проблема/забота юзера а не вендора материнки и тем более проца.

Сейчас UEFI с секуребутами привёл к тому что можно купить планшет/ноут но нельзя поставить туда что то другое, только долбаный софт вендора.
И интел (с амд менее открыто) всё больше затягивает удавку, превращая х86 из открытой свободной платформы в концлагерь огороженный заборами со всех сторон: секуре бут, шифрованные анклавы памяти…

Насчёт самой микрухи.
Я когда жаловался знакомым железячникам, они предложили написать эмулятор SPI который будет часть писать во флеш, часть в CMOS/RAM чтобы долговечность не страдала.

2 lorc
Проблема проверки начинки биоса всегда решалась программатором — 100% результат.

И да, я не покупаю больше интел.
Пока АМД.
Дальше или АРМ и/или что то отечественное.

Тонны опенсорсного софта есть под любую платформу на которой есть хоть какой то компилятор С для бутстрапа. Основная сложность это портирование линуха/бсд и уже потом выжимание всех соков.
1. ntkt
  19.04.2017 03:28
  #10180050
  +5
  Проблема доверенной загрузки вызвана, в первую очередь:
  
  реальными зловредами-буткитами;
  
  реальными злоумышленниками с кратковременным физическим доступом к железу ("evil maid attack");
  
  необходимостью обеспечения trusted path functionality для критически важных операций типа ввода пароля для полнодискового шифрования.
  К паранойе и/или копирастии это отношения не имеет. Все серьезные вендоры давно уже не борются с опенсорсом, а всячески его приветсвуют, т.к. он прямо и косвенно экономит им деньги и повышает лояльность пользователей.
  1. amarao
    19.04.2017 03:44
    #10180056
    +1
    Если они приветствуют опенсорс, то почему блобы шифрованные? Какой именно код скрывает Интел от владельцев устройства?
    
    ntkt
    20.04.2017 02:35
    #10182220
    +1
    Вендоры скрывают код не от владельцев устройств, а от конкурентов и прочих игроков, которые могут использовать найденные в нем фичи и баги по собственному усмотрению. А тот факт, что те же ME/AMT/… обладают de facto функциональностью бэкдора, это, на минуточку, открытая информация, они для этого и создавались. Вот в смартфонах последнего поколения, помимо пользовательской ОС, присутствует ещё чуть ли не с полдесятка полноценных операционных систем, например, почему же никто не поднимает шум по этому поводу?
    
    amarao
    20.04.2017 12:07
    #10182816
    +2
    Ну зачем вы передёргиваете? Вендоры хотят скрыть код от конкурентов, а скрывают от владельцев устройств. Мне пофигу на конкурентов, но мне не пофигу на то, что у меня на компьютере работает дярявый код, который никогда не проходил независимого аудита, полный дыр и бэкдоров неизвестно от кого (включая программиста, которого увольняют через 3 месяца и он решает «оставить прикол») — и никто на свете не может проверить так это или нет.
    
    Я бы сказал, что это паранойя, если бы не Сноуден и все викиликсы этого кода.
  1. Ivan_83
    20.04.2017 09:19
    #10182444
    1. Буткиты.
    Уверен что единственные буткиты которые интересуют идустрию это те что вливают SLIC для активации венды, и только с ними и сражаются.
    Второе это альтернативные ОС на планшетах и прочих девайсах, особенно которые мс датировала в надежде потом отжать бабло на впаривании всяких своих сервисов и продуктов.
    
    Обычным вирусописателям буткиты нафик не сдались, и если посчитать их наберётся сильно менее 1% от всего что есть. Буткиты это долго писать, сложно отлаживать и ограниченный функционал. Нахера тратить время на это когда тупых хомяков как песка на пляже?
    
    И лично меня буткиты вообще не колышат, мне переписать загрузчик/проверить его дело пары секунд и пары команд в консоле. Более того, я обновляю загрузчики с обновлением ОС, те не реже раза в три месяца.
    
    2. Глупости. Вон только недавно показывали как похачить мак без паролей вообще, подцепил девайс и готово.
    Тоже самое у интела с отладчиком через юзби3 порт.
    
    3. Это орг проблема, как и предыдущая.
    Нужна уверенность — носи загрузчик с собой в кармане на флешке или гарантируй отсутствие физ доступа. Флешку можешь тоже с типа аппаратным шифрованием и своей клавой взять, но это скорее для понта.
    То что твоя венда не может иметь загрузчик на отдельной флешке — твои проблемы, не нужно тащить их в железо.
    
    А вот к копирастии это имеет самое прямое отношение.
    1. Не давать юзрам грузить SLIC для безопасного хака активации.
    2. Не давать юзерам юзать железо ни для чего кроме венды
    3. Не давать юзерам сломать DRM — интел же сфакапилась и их ключик для шифрования в HDMI стал известен, вот они решили что теперь закопают это ещё глубже в железо, и сделали всякие анклавы памяти, ну и типа венду подлатать, а то там пароли весело дампятся прямо из памяти lsas процесса опенсорсной утилитой. Так то они всё ещё надеяться что смогут продавать киношки на дисках и их нельзя будет скопировать никак, ибо кругом шифрование и только на мониторе перед выводом оно расшифровывается. А там можно будет и вообще показы по одному продавать…
    АМД вон даже на радостях TPU прямо в райзен встроил. Первая то попытка с серийниками в процах пень 3 у интела провалилась — тогда их говном закидали, они долго отмывались, благо хомяков тогда было а было всё больше понимающей публики.
    
    Итого.
    Я ещё раз говорю: мне не нужна никакая долбаная криптография и епата с загрузчиками и биосами.
    Я хочу максимальной открытости, прозрачности и надёжности.
    Пусть лучше грузится всё что попало в нужные места, когда мне будет нужно я сниму диск и проверю на другой машине. Когда я буду сомневаться в содержимом биоса — лучше я его сниму и сделаю дамп на программаторе и проверю на соответствие с прошлым дампом.
    Пусть будет кмос, пусть будет джампер/переключатель, и пусть наконец будет открытый биос.
    
    И да. Касательно джамперов и пр хераты. Можно было вообще делать биос в ROM. Оч минимальный.
    Остальное подгружать уже с какого то съёмного носителя, примерно как сейчас микрокод может подгружатся и биосом и ОС. Это бы вообще сняло все проблемы с безопасностью и окирпичиванием при обновлении.
    То что всякие тайминги и прочие настройки которые в биосе есть можно менять из — уже давно не новость.
    
    Я не понимаю какого хера интел/амд там чего то скрывает, ведь явно никто не будет делать процы вместо них даже если разберётся во всей этой каше.
    Я не понимаю как подпись защитит меня от таргетированных атак, особенно ихних спецслужб, которые запросто откроют дверь интел/амд/вендора пинком и заберут все ключи для подписи всего потому что нац без под угрозой и тп.
    При этом я не понимаю кому кроме спецслужб придёт мысль убивать херову кучу времени чтобы туда лезть, когда можно срубить больше бабла меньшими силами.
    
    Поэтому нет, нихера не сходятся слова что это на благо юзера со здравым смыслом и логикой.
    Вот закручивание гаек планомерное и постепенное в пользу копирастов я вижу, тут сомнений нет кто получит профиты а кто будет вечно арендовать свой комп и весь софт.
    
    sumanai
    20.04.2017 15:47
    #10183348
    То что твоя венда не может иметь загрузчик на отдельной флешке
    
    А это разве действительно так? При установке да, не выберешь, но потом вроде ничего не мешает удалить стандартный раздел с загрузчиком и сделать свой на флешке. Так, примечание.
    
    ValdikSS
    28.04.2017 12:20
    #10195626
    +3
    Проблема в том, что вы под буткитами подразумеваете зловреда на уровне внешнего загрузчика, а в статье говорится, что вирус из ОС может установить буткит на уровне UEFI, причем таким образом, что вы не сможете его оттуда удалить перепрошивкой UEFI — мат. плата просто не запустится.
    
    Этот буткит может быть очень скрытный, активироваться по таймеру, периодически. Скажем, можно написать буткит, сканирующий всю RAM в поисках GPG-ключа каждые 5 минут. Он будет работать в SMM, ваша ОС ничего с ним не сможет сделать.
    
    Кроме того, вы путаете Secure Boot, Trusted Boot и Verified Boot. Это разные вещи, и мне кажется довольно глупым, что им придумали такие похожие по смыслу названия.
    В статье описывается Verified Boot. Trusted Boot, напротив, не ущемляет ваших прав как владельца, а дает возможность удостовериться, что вся цепочка загрузки не изменилась с момента предыдущего запуска.
    Скажем, вы оставили ноутбук в отеле, злоумышленник мог пробраться и подменить загрузчик, а Trusted Boot поможет вам убедиться, что в ваш ноутбук залезали без вашего ведома. Trusted Boot не блокирует ничего сам по себе, он только дает вам возможность проверить цепочку загрузки из вашего кода.
    
    Например, можно выводить значение TOTP на экран и проверять его на другом устройстве — телефоне, планшете. Если значение не совпало, значит, что цепочка доверенной загрузки нарушена. Можно просто автоматически доставать ключ шифрования жесткого диска из TPM, если все PCR-регистры доверенной цепочки совпали, а если не совпали, достать ключ не удастся.
    
    Для GRUB2 есть патч для поддержки Trusted Boot.
    Даже GNU не против него:
    
    В настоящее время “модули доверенной платформы” вообще не применяются для цифрового управления ограничениями, и есть основания полагать, что применять их для этого будет невозможно. Как ни парадоксально, это значит, что современные применения “модулей доверенной платформы” ограничены невинными второстепенными приложениями — такими как проверка, что никто не изменил украдкой систему на компьютере.
    
    Следовательно, мы приходим к заключению, что “модули доверенной платформы”, доступные для персональных компьютеров, не опасны, и нет оснований отказываться от включения такого модуля в состав компьютера или от поддержки его в системных программах.
    https://www.gnu.org/philosophy/can-you-trust.html

amarao
19.04.2017 03:42
#10180054
Я не понимаю вашей терминологии. Каким образом зашифрованный проприетарный блоб без возможности контроля и анализа может считаться основой доверия? Почему я, как владелец устройства, должен ему доверять?
1. mayorovp
  19.04.2017 07:45
  #10180178
  Вы доверяете не бинарному блобу — а производителю материнки. А если не доверяете — то нахрена покупали?
  1. amarao
    19.04.2017 12:57
    #10180822
    +1
    Я доверяю автобусу возить мою тушку (включая риски попасть в аварии), но я не доверяю автобусу ковыряться в моём кошельке, постить от моего имени в интернеты и не выдаю доверенность на распоряжение моей квартирой.

jamakasi666
19.04.2017 09:28
#10180348
Я вот считаю что все эти усложнения крайне лишние. Проблема зловредов? Да емое, тем кто будет писать зловреда такого уровня насрать на все эти защиты и он всеравно найдет дыру размером с боинг. В конечном счете страдают пользователи от всех этих защит намного больше чем он неведомого руткита который может туда засесть.
Почему нельзя сделать просто и надежно? Скажем так:
1) Ставим 2 микрухи биоса. 1 всегда только в режиме ro без любой возможности записи. 2я обычная.
2) Делаем 2 джампера\тумблера\чего угодно но главное физического. Первый тумблер переключает какая микруха биоса будет работать сейчас(1 или 2я), 2й джампер переключает ro\rw 2й микрухи биоса.
Что в итоге получилось бы:
1) если пользователь параноик то просто обновляет без проблем свой биос на 2й микре как ему угодно и переключает джампер в RO. Финал.
2) Если пользователь массовый то пусть будет какая угодно утилита автообновления в его любимой венде и будет обновлять ему биос 1 кнопочкой в системе или полным автоматом. Естественно с завода джампер должен быть переключен в RW. Финал.
3) Для энтузиастов или любителей поколупать кишки биоса, ковыряйте и шейте такими же штатными средставми что угодно. Сломалось? Переключаем джампер для перехода на микру 1го биоса который всегда в RO, грузимся с него в любимую систему и шьем 2ю микру рабочим биосом, возвращаем все джамперы назад. Финал.
Все были бы довольны, массовый пользователь мог бы и не знать всех этих тонкостей и все бы работало само как должно, гики остались бы довольны тем что могут смело ковырять что угодно и не писаться кипятком от «а если навернется то чем шить, где программатор брать?», параноики остались бы довольными т.к. от них никто не прятал бы бинарные блобы в местах к которым нельзя получить доступ и были бы уверены что никакая сферическая дрянь в вакуме не подсунет им в биос свой коварный код.

Да, я знаю что 2 микрухи биоса любит ставить гигабайт на своих десктопных матерях, меня такие спасали пару раз. Но к примеру, у меня есть ноутбук с солидным железом индусского производста(casper у них, у нас они под видами днсъдекспов и т.д.), в нем стоит довольно не слабая карточка от АМД но вот незадача, биос видеокарты не стали распаивать на видяхе а его ром запихнули в ром биоса. Тут наступает интересный момент, чтобы была возможность пользоваться самыми новыми дровами нужно прошить биос видяхи свеженькой версией, чтобы его прошить надо прошить uefi\биос всего ноутбука и угадайте что? Правильно, все это прибито «гвоздями, сертификатами, всякими секюрами». В итоге я даже с пониманием как все это сделать немогу этого сделать =), на 10ке пришлось долго шаманить чтобы заставить карточку заработать с 1й единственной версией дров и то не без проблем. В целом все работает замечательно но вот только карта амд инициализируется аккурат в конце загрузки винды и в итоге в этот момент я вижу секунд 30 черный экран.

А как вариант того ччто многие производители кастрируют свои биосы оставляя возможность только выставления времени и приоритета загрузки? Раньше можно было чуть подшаманить биоса каким нибудь фениксом и разлочить все нужные пункты. Сейчас ничего не сделаешь чаще всего. В итоге перед покупкой нотбука\материнки добавился пунктик найти и посмотреть что там есть в биосе\uefi\efi.
1. BlessMaster
  19.04.2017 09:48
  #10180370
  тем кто будет писать зловреда такого уровня насрать на все эти защиты и он всеравно найдет дыру размером с боинг
  Именно поэтому нет смысла закрывать квартиру/автомобиль/сейф на замок и все именно так и поступают, оставляя двери открытыми? :-)
  1. jamakasi666
    19.04.2017 10:33
    #10180448
    «Замок» у вас остается в виде джампера\тумблера а закрывать или нет проблема сугубо твоя. А так даже абмарный замок и стальная дверь с кучей камер не спасут вашу квартиру если кто то задался целью проникнуть в нее. Сейф тупо утащат и раз*бут в спокойствии в гаражах. А автомобиль угнать сейчас вообще не проблема, покупаешь за 10к рублей кодграббер и открываешь любую машину у которой есть сигнализация а если есть еще и автозапуск то еще и покатаешься на ней. Так что ваш пример не к месту и не корректный.
    
    ntkt
    20.04.2017 03:08
    #10182230
    Причины отсутствия нормальной криптографии в противоугонных системах — это больная тема, достойная отдельной теории заговора. Видимо, там сошлись воедино инерция рынка, патентные коллизии пополам с синдромом "not invented here" и квалификацией разработчиков, традиционная для отрасли парадигма "security through obscurity", высокие затраты на разработку при жестокой конкуренции, агрессивный risk management а ля "в среднем и так сойдет", и т.д.

madkite
19.04.2017 13:00
#10180830
А там Интел не придумали, случаем, механизм отзыва ключей на случай, если их приватный ключ утечёт?