Pull to refresh
25
0
Александр Ермолов @flothrone

Reverse engineer

Send message
Т.к. речь зашла о том, какие серьезные уязвимости в Intel ME были найдены после выпуска этой статьи, то замечу, что, в хронологическом порядке, первая будет эта (о ней мы рассказывали на BlackHat USA 2017 и GSEC HITB 2017).

Думаю, что эти находки не будут последними)
Интересный материал, спасибо.
можно активировать без каких-либо аппаратных модификаций (при наличии JTAG линий между PCH и CPU).
Любопытно было бы почитать про ваш опыт восстановления JTAG соединения между чипсетом и процессором.
MEinfo есть под DOS.
И вам нужна правильная версия: т.к. чипсет Z68, то ME firmware у вас должно быть версии 7.x, следовательно, использовать нужно MEinfo из комплекта 7-й версии.
Intel® ME Firmware Version: No

Это неточность. В моём распоряжении есть мат. плата на чипсете Intel H67, для которого тоже сказано, что ME firmware version: no, однако MEinfo говорит об обратном.

Данное поле, кстати, отсутствут в описаниях на ark.intel для чипсетов 7 серии и далее.
если судя по официальной спеке Intel ME отсутствует на этом чипсете

И что за спецификацию на чипсет вы там читаете, если в даташите на этот чипсет есть описание регистров MEI (Management Engine Interface) в конфигурационном пространстве PCI?
И, мне сдаётся, вы путаете понятия Intel ME и Intel AMT. Первое — подсистема, основным компонентом которой является микроконтроллер, интегированный в наши чипсеты. Это подсистема являетя программно-аппаратной поддержкой для технологий компании Intel, в т.ч. Intel AMT, которая имплементирована в виде нескольких кодовых модулей, входящих в состав прошивки Intel ME. Другими словами, Intel ME — движок, основа. Intel AMT — лишь часть прошивки Intel ME.
Насчёт интегрированности ME во все чипсеты начиная с 2010 года — вообще это давно известный факт, скачайте прошивку к своей материнской плате и проверьте наличие ME региона в ней (который содержит прошивку Intel ME). Надеюсь вам этого будет достаточно.

Чтобы убедиться в том, что ваш Intel ME живет и функционирует нормально, юзайте утилиту MEinfo.
ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше. Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен. Другое дело, что этот чипсет не имеет оф. поддержки Intel vPro (Intel AMT), а значит эта технология (AMT) скорее всего выключена, и уязвимость (о которой идёт речь) удалённо проэксплуатировать не выйдет.
Технические подробности найденной в коде Intel AMT уязвимости (CVE-2017-5689) уже опубликованы.
Благодарю.
Фоном занимаюсь как раз изучением механизмов верификации прошивки в системах Dell. Так что, вероятно, сделаю в будущем материал по теме.
Абсолютно согласен.
Да, WP-джампер сейчас применяется (путём разнесения модифицируемых и немодифицируемых участков прошивки) редко где. Я слышал только о некоторых моделях систем Dell.
Нет, не с помощью этих. Другая утилита нужна — me_cleaner. Позволяет вырезать часть прошивки Intel ME, основные кодовые модули (загрузчик, ядро и прочие) никуда не деваются.

Метод не у всех стабильно работает (см. ветку issues), поэтому пользоваться me_cleaner без наличия программатора (т.е. без возможности, в случае чего, выпаять флеш-память и вернуть «как было») крайне не рекомендуется.
Понятно. Встречали ли вы системы, где возможно использование DCI с P2SB-устройства, т.е. без предварительной модификации содержимого SPI флэш-памяти? Если не секрет, то что за устройство, или хотя бы, что за вендор?
Посмотрел видео доклада (с 33c3), очень интересно. Есть несколько вопросов.

1) правильно ли я понимаю, что перед тем как вставить USB устройство, которое будет использовать технологию DCI (например, с целью провести атаку) необходимо предварительно попасть на атакуемую машину чтобы включить технологию DCI (пропатчив BIOS или выставив соответствующий бит в регионе Flash Descriptors на SPI флэш-памяти)?

2) только один из имеющихся USB 3.0 портов. может использовать DCI. Возможно ли, что этот порт не выведен на фронтальную или заднюю панель системного блока, а находится например на самой материнской плате (бывает, что прямо из материнки вверх торчит USB гнездо), или же вообще не распаян?
Верно. ME старых версий (до 6.x и на тех чипсетах, где он присутсвовал), можно было вырубить установкой флага ME disable (при сборке образа SPI флеш-памяти с помощью Intel Flash Image Tool). Я писал в своей статье про ME об этом.

Действительно, прошивку ME можно было вырезать из флеш-памяти без потери работоспособности платформы. Впринципе, это можно считать гарантией того, что ME выключен и не исполняет никакой код.

Начиная с 6.x версии, когда ME стал обязательным компонентом, вырезать ME регион не потеряв работоспособности системы уже не так просто.
Видимо, имелось ввиду то, что до 2009 года подсистема Intel ME встраивалась только в чипсеты, поддерживающие AMT (vPro). Т.е. если у вас платформа старше 2009 года, и чипсет не из линейки Q, то Intel ME у вас нет.

Встраивать во все чипсеты ME начали с 5 серии (ME 6.x), тогда же появились Intel Core i3/i5/i7. Поэтому, если у вас Core 2 Duo, скорее всего на вашей платформе нет ME.
Насчёт стандартных утилит/драйверов для ОС: у Windows они входят в комплект ПО Intel ME, предоставляемый компанией Intel или распространяемый вендором компьютерой системы. Для Linux точно ответить не смогу, но, проведя аналогию, предполагаю, что они есть в драйверах от Intel.

Специальных утилит для Linux от Intel для работы с AMT (например, ACUwizard, который я упоминал в статье) я не знаю, но, на крайняк, есть Intel AMT SDK.

Linux-версий утилит из System Tool Kit (для работы с образами флеш-памяти и с подсистемой Intel ME) нет, но, почти для всех утилит рядом лежат DOS-версии. Замечу, что не имеющие DOS-версий утилиты не используют интерфейс HECI, просто работая с образами прошивок, поэтому их можно запустить на виртуалке.
В «живой природе» выловить такое не удалось, видимо это вопрос времени,
но патент и настройки для этой функции в Flash Image Tool для PCH есть
уже сейчас.


Я так и подумал (в презентации на слайде 5, приведен рисунок из патента). Однако в патентах, имеющих отношение к ME, много чего написано, не имеющего отношение к действительности.


Тут имелось ввиду, что UMA используется как swap бортовой SRAM. Кеш для
ME — это сам SRAM.


А это из какого патента?

Кэш кода/данных это кэш ME-контроллера. ME SRAM — отдельное внутреннее ЗУ, ME ROM (со стартовым кодом, тоже, кстати, кэшируется) — отдельное внутреннее ЗУ, ME UMA – область в оперативной памяти компьютерной системы.

Содержимое этих областей спроецировано в адресное пространство ME-контроллера.


1. В прошивках, которые были исследованы, SPI активно используется в процессе работы. При обновлении ME вынужден блокировать доступ к Flash, что приводит к отключению критических для ME функций.


Критических это каких?

Допустим, после получения сообщения HMR FPO (о нём упоминается на слайде 20 в презентации) в HECI, ME не трогает флеш-память, а значит, прошивку. Но до этого момента он уже успел загрузить весь (или почти весь) свой код в ME UMA (это показывает, как минимум тот факт, что HECI работает, через который ME получает сообщение). Следовательно, до этого момента ME-контроллер успеет выполнить определённое количество кода и нет доказательств того, что он не будет исполнять загруженный код и дальше, пусть и деактивировав некоторые внешние интерфейсы.


2. Сбой Dram Init Done на самом деле не является запросом к ME на отключение, а просто имитирует аппаратный сбой, что заставляет ME
переходить в режим бездействия.


А в чём заключается режим бездействия? В презентации на слайде 14 упомянута «ошибка», что под этим подразумевается? Генерация исключения? Это приведёт к ресету компьютерной системы.

Не оповещение ME-контролеру о DRAM Init Done приведёт к тому, что он не будет использовать ME UMA, но остаётся ещё ME SRAM, и доступ к SPI флеш-памяти (т.е. к своей прошивке) никуда не делся.


3. Режим Manufacture Mode — специальный режим, который предназначен для отладки оборудования при производстве, опять таки те прошивки, которые попадались действительно выключали ME, не только KVM, но и устройство перестает отвечать на любые запросы и еще много косвенных доказательств.


Если верить документации (например, из System Tools Kit), ME выключен на платформе в режиме Manufacture Mode (в следствие HDA_SDO или настроек в flash descriptors). Но как вы в этом убедились?

На мой взгляд «косвенных доказательств» (наблюдение ограничения функциональности Intel ME т.е. отключения внешних интерфейсов, в т.ч. HECI) недостаточно, чтобы однозначно утверждать, что подсистема Intel ME не функционирует вообще, никакого кода не исполняется, и она не «проснётся» при возникновении какого-либо события извне.

К тому же, в презентации на слайд номер 26 приводится список компьютерных систем, где, если я правильно Manufacture Mode включен out-of-the-box? Вы хотите сказать, что у счастливых обладателей этих систем, ME уже выключен? :)


4. Возвращаясь к UMA и выключению канала. Как сказано в презентации, сам по себе этот способ убивает машину через не более чем 40 секунд,
но его можно использовать как косвенный показатель того, что ME действительно не функционирует


Имхо, это больше сбой в работе контроллера памяти. В любом случае, это DoS платформы, а не способ отключения Intel ME.


«выдираем» у ME процессора данные и код, объем ядра и базовой обвязки у МЕ больше чем SRAM, функционировать без UMA в «полную силу» ОС МЕ контроллера не может.


А какого размера SRAM у ME? Какие кодовые модули в прошивке вы считаете базовой обвязкой? Спрашиваю конкретные цифры, чтобы убедиться в нехватке места.
Без ME UMA «в полную силу» подсистема не функционирует, но ограничение функциональности не означает отключение.


5. В какой то степени мы доверяем, что ME выключает сам себя (можно взять модуль, найти обработчик указаной команды и удостовериться в
этом). Но исследователи представили метод для косвенного доказательства отключения МЕ.


А вы анализировали этот обработчик? Т.е. всю цепочку исполнения кода от начала принятия команды на выключение до окончания её обработки и перехода в «режим бездействия»? Если да, то не могли бы подробнее описать, что там происходит? И для какой версии Intel ME firmware?


Подается, он висит в бесконечном цикле.


Почему он оказывается в бесконечном цикле? Как вы в этом убедились?
В демке, насколько я понял, была отправлена команда на отключение ME в HECI, значит, в результате принятия этой команды? Опять же, возникает вопрос про обработчик, который я задал выше.


В заключение скажу, что способов, описанных в открытых (патенты, спецификации на чипсет и процессор, форумы, книги по ME) и полуоткрытых (System Tools Kit) источниках явно недостаточно, для того, чтобы выключить подсистему Intel ME. Исследователи и разработчики, которые занимаются/интересуются этим вопросом довольно продолжительное время в один голос твердят об этом (пруф, пруф, пруф, пруф, ещё можно спросить «как дела с отключением ME?» у разработчиков проектов на основе свободного ПО, например Purism).
Неужели всё так просто?

Повторюсь, все эти способы:
  • либо приводят к DoS (почти сразу или через несколько десятков минут);
  • либо не гарантируют того, что подсистема Intel ME действительно выключена.


Либо и то и другое :)

Соглашусь с комментариями выше в этой ветке: чтобы гарантировать неисполнение кода ME-контроллером следует отнять у него этот код, удалив прошивку из ME-региона и добиться полной работоспособности платформы. И даже в этом случае, останется код в ME ROM, содержимое которого, в production-версиях компьютерных систем неизвестно.
Технология Intel ME (или AMT, Active Management Technology)


Intel ME и AMT это не одно и то же. AMT является лишь программной составляющей, т.е. она аппаратно-поддержана подсистемой Intel ME.

Кроме того, подсистема содержит потенциально опасные функции — удаленное управление, NFC, скрытый сервисный раздел (hidden service partition).


А вы проверяли наличие скрытого сервисного раздела?

UMA — это часть памяти хоста, которая используется как подкачиваемая память (swap)


То, что, ME UMA кэшируется не означает, что это память подкачки (swap). ME SRAM тоже кэшируется.

Один из исследователей подсистемы Intel ME (и людей, нашедших уязвимость в чипсете Q35), Joanna Rutkowska, посмотрев вашу презентацию, отметила, что, представленные в презентации способы «отключения ME»:
  • либо приводят к DoS всей платформы;
  • либо являются запросом к подсистеме Intel ME на отключение самой себя.

Таким образом, если мы доверяем тому, что Intel ME отключила сама себя, то почему бы не доверять этой подсистеме в целом и прекратить попытки её «вырезать»?

От себя добавлю, что судить об отключении Intel ME только по отвалившемуся сетевому интерфейсу (в демке) неправильно. С чего вы взяли, что эта подсистема действительно не функционирует? Представленный в статье аргумент не понятен. Если, у ME-контроллера нет внешней памяти (UMA), он использует внутреннюю SRAM. Где здесь отключение?

Неужели на ME-контроллер не подаётся питание? Или подлинно известно, что он перестаёт исполнять код (например, халтится)?
Intel ME есть в абсолютно всех выпускаемых на данный момент чипсетах/SoC от Intel.
Так что, продукция Apple, на которой используются чипсеты и процессоры Intel, — не исключение.

Если, AMT (хотя я не видел, чтобы у Apple девайсов была оф. поддержка Intel vPro) не включена, по идее ME не должен лезть в сеть. По идее.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity