Bios lock в bios что это
Данная инструкция позволит выполнить анлок турбо-буста наиболее современным методом, с помощью утилиты S3TurboTool.
За данную утилиту и новый драйвер анлока стоит благодарить ser8989.
Этот метод имеет весомые преимущества как перед классическим способом анлока через EFI-shell, так и перед методом с встраиванием FFS-драйвера в биос. Анлок через S3TurboTool:
- Достаточно выполнить 1 раз, не слетает при смене операционной системы или компонентов ПК
- Удобен, весь необходимый софт уже включен в дистрибутив программы
- Универсален, будет работать с любыми операционными системами
- Не слетает после выхода ПК из режима сна
- NEW: Позволяет интегрировать DXE-драйвер для двухпроцессорных систем (начиная с версии S3TurboTool_v1.41)
- NEW: Позволяет отключить звук встроенного бипера (начиная с S3TurboTool_v1.5)
- NEW: Позволяет создать RAW-драйвер (начиная с S3TurboTool_v1.53). Как и PEI, RAW-драйвер предназначен для односокетных систем и также не слетает после выхода системы из сна. Он предназначен для плат, биос которых не содержит модуль PchS3Peim, а значит использование PEI-драйвера в них невозможно.
Помимо удобства применения и массы настроек, рабочий анлок после выхода из сна — основное преимущество S3TurboTool над другими методами. Также благодаря новому драйверу было уменьшено энергопотребление процессора без нагрузки.
Использование PEI-драйвера было протестировано на биосах от Huananzhi x99 TF и F8\T8, но работает и на других китайских платах, биос которых содержит модуль PchS3Peim. Для плат без данного модуля полноценный анлок стал возможен с помощью RAW-драйвера.
Подготовка
Как обычно, все действия выполняются исключительно на свой страх и риск.
- Убедитесь, что используете подходящий процессор (Haswell степпинга pre-QS и выше). Подробнее о степпингах здесь.
- Убедитесь, что система охлаждения выдержит увеличившуюся после применения хака температуру.
Необходимый софт
Все необходимые утилиты уже включены в программу S3TurboTool, скачать её можно чуть ниже. Помимо неё нам понадобится только дамп биоса для используемой материнской платы.
-
S3TurboTool_v1.1_S3TurboHack_v0.2
Версия 1.1
Размер файла: 18 MB Кол-во скачиваний: 6405S3TurboTool_v1.41_S3TH_v1.0_DXETH_v1.0_beta
Версия 1.41
Размер файла: 18 MB Кол-во скачиваний: 1859S3TurboTool_v1.5_cat_S3TH_v1.0_DXETH_v1.0_beta
Версия 1.5
Размер файла: 18 MB Кол-во скачиваний: 3127S3TurboTool_v1.53cat_S3THv1_DXETHv1_RAWTHv1b
Версия 1.53
Размер файла: 18 MB Кол-во скачиваний: 10167
В некоторых платах (в основном производства Jingsha) биос защищен от записи, поэтому FPT при попытке прошивки будет выдавать ошибку error 280. К счастью, решение довольно простое: в биосе идем в IntelRCSetup > PCH Configuration > Security Configuration и меняем значение пункта Bios Lock на Disabled. После сохранения настроек и перезагрузки защита от записи будет снята.
Можно использовать как дамп родного биоса (снять его также можно через S3TurboTool), так и сторонние биосы, подходящие для вашей платы. Не следует использовать версии с уже интегрированным по старому методу FFS-драйвером.
Шаг 1. Удаляем микрокод 6F 06F2
Если для модификации выбран биос с уже вырезанным микрокодом, просто пропустите данный шаг.
Шаг 2. Настраиваем CPU C State Control
Шаг 3. Собираем драйвер анлока
- В S3TurboTool нажимаем кнопку «Собрать драйвер»
- Настраиваем необходимые оффсеты напряжения. Core — напряжение на ядра процессора, его понижение обычно даёт наиболее заметный результат. Как правило большинство моделей работают стабильно в диапазоне от -30 до -60, более удачные экземпляры до -100, процессоры с индексом L до -120. Cache (uncore) - обычно выбирается значение -50\-60, но на практике оно легко может превышать и -120. Проверяется стабильность кэша программой LinX с AVX-инструкциями или программами, сильно нагружающими память (к примеру TestMem5). Существует мнение, что сильный андервольт кэша ведет к нестабильности и увеличению таймингов ram.Sys agent — часто имеет значение -50, но как правило понижение напряжения этого модуля не даёт видимых результатов, поэтому можно и вовсе не трогать его.
- Оставляем галочку «Разблокировка турбо», а вот пункт «Использовать баг SVID\FIVR» лучше оставить для энтузиастов и галочку с него снять.
- По желанию, можно добавить в драйвер код биппера. Звучать он будет при выходе из сна и на стандартные звуки спикера не повлияет.
- Нажимаем на кнопку «Собрать драйвер» и получаем уведомление, что созданный файл находится в папке «S3TurboHack».
Баг SVID/FIVR это так называемый vcc1.8 в других драйверах, при определённых значениях SVID/FIVR сносит крышу и так как потребление определяется с ошибкой в меньшую сторону слетает ограничение TDP, использовать крайне осторожно у меня на 2678v3 в тесте линкс потребление поднимается по ваттметру до 430 ватт. -ser8989
Шаг 4. Добавляем драйвер в биос через UEFITool
Шаг 5. Прошиваем биос
Нажимаем кнопку «Прошить биос», указываем путь к нему и наблюдаем за процессом прошивки. После выполнения перезагружаем систему.
Если во время прошивки программа выдает error 200 — не стоит пугаться. Скорее всего, путь к файлу слишком длинный. Перенос в корень диска исправит ситуацию.
Шаг 6. Проверяем
Для проверки можно использовать программу HwInfo, которая показывает частоты для каждого ядра. Параллельно можно запустить какой-либо бенчмарк или стресс-тест (например cpu-z), чтобы нагрузить процессор.
Если всё прошло удачно — частота каждого ядра будет равна максимальному значению турбо-буста процессора.
Видео-инструкции
В видео формате все описанные действия можно посмотреть в следующих роликах:
Как добавить DXE-драйвер для двухпроцессорных систем
Начиная с версии S3TurboTool_v1.41_S3TH_v1.0_DXETH_v1.0_beta в программе реализовано создание DXE-драйвера, корректно работающего в двухпроцессорных конфигурациях (ранее для подобных систем анлок можно было реализовать только с помощью EFI-драйверов). Ниже приводится краткая инструкция по добавлению драйвера, оригинал которой находится здесь.
Как добавить RAW-драйвер для однопроцессорных систем
Использование RAW-драйвера оправдано для тех плат, в биосе которых нет модуля PchS3Peim, а значит использование PEI-драйвера в них невозможно.
ВНИМАНИЕ! После установки RAW драйвера не редактируйте этот биос любыми программами, в противном случае биос станет неработоспособным, если прошить такой биос то материнская плата «ОКИРПИЧИТСЯ», восстановить работоспособность будет возможно
только с помощью программатора.
- В S3TurboTool нажимаем "Собрать драйвер"
- Нажимаем в верхнем правом углу кнопку RAW и в открывшемся проводнике выбираем необходимый файл биоса
- Настраиваем необходимые смещения напряжения. Нажимаем «Собрать и установить драйвер»
- Файл биоса с новым названием сохранился в ту же папку и готов к прошивке. Прошить его можно также соответствующей кнопкой в S3TurboTool.
Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.
Введение
С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM'ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.
Тестовая конфигурация
Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:
1. AMI, они же "треугольные": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, они же "квадратные": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, они же "полукруглые": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
Об интерфейсах для настройки SecureBoot
На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool'а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.
Готовим плацдарм
Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.
Генерируем собственные ключи для SecureBoot
Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.
Генерируем ключевые пары
Конвертируем открытые ключи в формат ESL
Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.
Подписываем ESL-файлы
Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца.
Ну тогда вам прямая дорога вот сюда, там в самом конце раздела 1.3.4.3 есть ссылка на сертификат Microsoft Corporation KEK CA 2011 в формате DER, из которого нужно сначала получить PEM командой
затем сконвертировать полученный PEM в ESL командой
после чего добавить получившийся файл к нашему файлу KEK.esl командой
Теперь Microsoft такой же авторизованный пользователь вашей платформы, как и вы сами, с чем я вас и поздравляю.
С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:
Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:
Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.
Подписываем загрузчик
Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.
В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.
Укрощение строптивого
AMI AptioV
Insyde H2O
Phoenix SCT
Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:
Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool'а, иначе на этой платформе его запустить не получится:
Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool'а заканчивается вот так:
При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.
Заключение
В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.
Продолжаем начатый в прошлом посте разговор о безопасности UEFI, об угрозах и имеющихся защитах от них.
В этот раз речь пойдет об SMM, о том, как он устроен и работает, и почему является желанной целью для атаки.
Пропустившим нулевую и первую части сего опуса — рекомендую прочесть сначала их, остальных покорно прошу под кат.
Часть вторая. SMM
Немножечко ликбеза
Аппаратное SMI
Писать про него особенно нечего: подаем напряжение на ногу — имеем прерывание. Сейчас используется редко, т.к. почти на всех системах теперь имеются мультифункциональные GPIO, которые могут генерировать события, не прерывая работу ОС, плюс не нужна дополнительная логика для определения, кто же конкретно сгенерировал аппаратное SMI, ведь устройств много, а нога — одна.
Системные SMI
Программные SMI
Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.
Как реализован SMM
Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS'ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.
Атаки на SMM и защита от них
Забытый D_LOCK
Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.
SMM cache poisoning
Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.
SMM call-out, она же SMM incursion attack
Но достаточно истории, перейдем к «современным» атакам. Начнем, пожалуй, с той самой SMM Incursion Attack, о которой тов. maseal упомянул в комментарии к первой части. Я специально поставил слово «современные» в кавычки, ибо этой атаке — сто лет в обед, впервые о ней сообщали еще в 2008 году как проблему тогдашних BIOS'ов, но в 2015 ее вновь переоткрыли Corey Kallenberg и Xeno Kovah. Атака простая как мычание — если обработчик SMI вызывает какой-либо код, находящийся вне SMRAM, то атакующий с правами на запись в физическую память может подменить вызываемый код на свой, и выполнить его таким образом в режиме SMM. А т.к. разработчики UEFI привыкли к доступности EFI Runtime-сервисов, то эти самые сервисы стабильно вызывались из обработчиков SMI на каждый чих (чаще всего это были вызовы GetVariable, SetVariable и ResetSystem). Уязвимости оказалось подвержено столько систем, что проще сказать, где их не было. По моей грубой оценке, если ваш UEFI старше мая-июня 2015 года по build date, в нем гарантированно имеется пара уязвимых к этой атаке обработчиков SMI. Вычистить систему от таких глючных обработчиков достаточно сложно, и т.к. раньше такое поведение вообще не считалось уязвимостью («какой дурак полезет сервисы хукать то?!») и о том, что так делать нельзя, не было известно простым IBV 'шным кодерам — даже сейчас периодически приходят обновления для runtime-драйверов, подверженные этой проблеме. Все очень грустно, в общем.
Для защиты от вызова внешнего по отношению к SMRAM кода инженеры Intel добавили специальный MSR_SMM_FEATURE_CONTROL, после установки определенного бита в котором вызов такого кода генерирует немаскируемое и невосстановимое MCE , но есть такой MSR только в Haswell и более новых CPU, да и включается эта возможность только на время отладки прошивки, иначе за непонятные зависания на ровном месте пользователи могут к дверям отдела R&D прийти с вилами и дубьем — большинству нужно, чтобы работало и сейчас, а эта ваша безопасность вся — overhyped. Для обладателей более старых систем и систем на базе процессоров AMD инженеры Phoenix нашли по своему гениальное решение — использовать NX-бит, настроив память для SMM-кода таким образом, чтобы вызов кода вне SMRAM заканчивался Page Fault'ом, который затем можно обработать, а не висеть намертво на MCE. Каюсь, я у себя пока еще это решение не внедрил, но когда дойдут руки — обязательно это сделаю.
Простому же пользователю от этой атаки можно защититься только не допуская исполнение непонятного кода от рута, но это, к сожалению, на современных ОС практически нереально — вариантов локального повышения прав как было море, так и остается, сколько таких 0day-эксплоитов на руках и в обороте, сказать невозможно. Остается только процитировать вышеупомянутого Xeno Kovah:
DMA attack
SMM cross-buffer attack
Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.
Заключение
Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
Спасибо за внимание, безопасных вам прошивок.
P.S.
Не могу не поблагодарить тов. d_olex за его статьи об SMM и атаках на него — раз и два. Для интересующихся темой и умеющих читать по-английски — обе обязательны к прочтению.
Привет! Недавно я уже подробно рассказывал — что такое BIOS и CMOS. Сегодня я поподробнее остановлюсь на том какие бывают виды БИОСа, потому как разобраться в этом начинающему пользователю сложно. Хотя, на самом деле, всё весьма просто — надо лишь в этом немного разобраться. Тем более, что несмотря на различия во внешности, в плане настройки функций и принципах действий все они схожи. Я расскажу какие виды бывают и покажу всё это в картинках.
На текущий момент есть 3 основных разновидности BIOS отличающиеся по производителю.
1. AMI BIOS
American Megatrends inc. — это, наверное самый старый разработчик. АМИ БИОС шел ещё во времена моего детства на древних 286-х и 386-х компьютерах. Затем, на какое то время, этот вид пропал. Но последние годы снова появился, причём именно AMI — самый распространённый вид BIOS на ноутбуках ASUS, MSI, Lenovo. На текущий момент есть две основные ветки:
— версия 2.XX. Выглядит она так:
Эту версия АМИ БИОС отличается от всех других по структуре главного меню и серо-синей цветовой гамме.
— версия 3.XX.
Эта ветка уже внешне и по своей структуре больше напоминает классическую систему ввода-вывода от AWARD.
2. Phoenix BIOS, он же Award
Ранее это были две разные фирмы, выпускающие каждая свою систему. Система от Авард многие годы была лидирующей на рынке. А вот Феникс БИОС был не особо популярен у производителей материнских плат. Но дальше происходят интересные события — AWARD Software был перекуплен Phoenix. Сейчас это одна фирма. А вот торговых марок несколько:
— Award BIOS
— Phoenix Award BIOS
— Phoenix Award Workstation
Различий между ними почти нет — интерфейс полностью идентичный. Есть, правда исключение — версия Феникс-Авард для ноутбуков. Она внешне очень похожа на АМИ:
Сегодня именно этот вид БИОСа используется на 90% материнских плат стационарных компьютеров.
3. Intel BIOS
Компания Intel на свои фирменные платы ставит свой фирменный вид БИОСа. Вернее он не совсем их — это модифицированная версия АМИ. До некоторого времени на материнских платах шла версия Intel/AMI 6.0, а позже, когда она была ещё более существенно переделана, изменены опции и переделан интерфейсе — этот вид БИОСа стал носить название — Intel.
Последние версии вообще визуально больше стали похожи на UEFI назывались «Intel Visual BIOS»:
4. UEFI
Начну, пожалуй, с самой современного вида БИОСа — UEFI (Unified Extensible Firmware Interface). Это даже не разновидность а наследник или преемник, кому как удобнее называть. УЕФИ — это следующая ступень в развитии BIOS. Сейчас, фактически, это уже не просто система ввода-вывода — она скорее похожа на операционную систему как внешне, так внутренне.
Наконец-то добавлена поддержка мыши! Среди ключевых особенностей — расширяемое множество возможностей, приятный визуальный интерфейс, возможность безопасной загрузки «Secure Boot», простота обновления микропрограммы, быстрая загрузка операционной системы.
Кстати, на некоторых материнских платах можно выйти в Интернет даже не загружая полностью компьютер — сразу из UEFI.
Ещё одна очень важная особенность — мульти-языковая поддержка, в том числе и русского языка.
Как узнать вид и версию БИОС на своей материнской плате?!
Это очень просто сделать практически на каждой современной материнской плате. Зайдя в БИОС или УЕФИ обратите внимание — вид и версия БИОСа написана, как правило в самом верху или в самом низу экрана:
Примечание: У каждого вида BIOS есть своя система диагностических звуковых сигналов, оповещающих пользователя при появлении различных неисправностей. Подробнее о них Вы можете узнать здесь: Award, AMI, Phoenix.
На материнских платах среднего и дорогого ценового сегментов от фирмы Asus можно обнаружить кнопку, подписанную как BIOS_FLBK или BIOS Flashback. Располагаться она может как на самой плате, так и на задней ее панели рядом с разъемами.
Кнопка в нижней части мат. платы
В данной статье мы рассмотрим назначение этой кнопки, и ситуации, в которых она может здорово выручить.
Обновление BIOS с флешки
Обновление BIOS на современных платах является достаточно простой и стандартной процедурой. Осуществляется она, как правило, через отдельный пункт в его настройках или же прямо из-под операционной системы.
Но что делать, когда процессор не запускается из-за старой версии BIOS материнской платы? Такое часто бывает при покупке очень свежего процессора. В таком случае нужно искать другой процессор под ваш сокет, чтобы с его помощью запустить компьютер и обновить BIOS.
Именно для таких ситуаций и была придумана функция USB BIOS Flashback. С ее помощью вы можете обновить BIOS своей мат. платы, не запуская ее.
Кнопка на задней панели платы
Все, что Вам нужно сделать, чтобы обновиться, это скачать последнюю версию BIOS с сайта поддержки, сбросить файл обновления на флешку, вставить флешку в USB порт мат.платы и нажать на кнопку BIOS_FLBK.
Работающая функция USB BIOS Flashback
Запустится процедура обновления, о чем будет свидетельствовать мигающий светодиод возле кнопки BIOS_FLBK.
Как только он перестанет мигать, это будет означать, что обновление BIOS завершено и можно запускать компьютер.
Вывод
BIOS_FLBK это кнопка, активирующая функцию USB BIOS Flashback, которая позволяет обновить BIOS материнской платы без запуска самой платы.
Читайте также: