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

На прошедшем 17 и 18 мая в Москве форуме Positive Hack Days VI исследователи Positive Technologies Максим Горячий и Марк Ермолов представили несколько техник отключения Intel ME, сопроводив доклад видеодемонстрацией процесса.

Что это, и зачем нужно отключать


Подсистема Intel Management Engine (ME) представляет собой дополнительный «скрытый» процессор, который присутствует во всех устройствах на базе чипсетов Intel (не только в PC и ноутбуках, но и в серверах). Среда исполнения ME никогда не «спит» и работает даже при выключенном компьютере (при наличии дежурного напряжения), а также имеет доступ к оперативной памяти, сетевому интерфейсу, USB контроллеру и встроенному графическому адаптеру.

Несмотря на столь обширные возможности, существуют вопросы к уровню защищенности ME — ранее исследователи уже находили серьезные уязвимости и векторы атак. Кроме того, подсистема содержит потенциально опасные функции — удаленное управление, NFC, скрытый сервисный раздел (hidden service partition). Интерфейсы подсистемы ME недокументированы, а реализация закрыта.

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

Хорошая новость заключается в том, что способы отключения ME все же существуют.

Техники отключения Intel ME


Исследователи компании Positive Technologies Максим Горячий и Марк Ермолов в ходе состоявшегося в Москве форума Positive Hack Days VI представили доклад, посвященный отключению Intel ME. Специалисты описали несколько техник отключения данной подсистемы:

  1. Основанные на сбое инициализации ME;
  2. Через механизм обновления микропрограммы ME;
  3. Недокументированные команды
  4. Недокументированный механизм, предназначенный для разработчиков аппаратуры — Manufacture Mode.

Исследователи установили, что разработчики аппаратных платформ часто забывают выключать режим Manufacture Mode, что позволяет использовать последний метод на большом количестве компьютеров без каких либо дополнительных затрат в режиме «реального времени».

Большинство методов отключения используют встроенные механизмы ME, разработанные для вендоров устройств на платформе Intel. Все они подробно описаны в презентации, которая опубликована на GitHub. По ссылке представлено демонстрационное видео отключения ME (оно же ниже):



И тем не менее, возникает резонный вопрос: «Действительно ли ME перестает работать в полном объеме при использовании ее встроенных механизмов отключения?» В качестве доказательства факта отключения МЕ исследователи приводят следующий аргумент: ME работает в двух режимах использования памяти: только SRAM (встроенный в ME) и SRAM + UMA. UMA — это часть памяти хоста, которая используется как подкачиваемая память (swap). После инициализации DRAM-контроллера хостом ME всегда переключается в режим SRAM + UMA.

Таким образом, если ME действительно выключена, то при отключении на аппаратном уровне доступа МЕ к UMA-памяти в произвольный момент (посредствам канала VСm), в МЕ не будет происходить аппаратных сбоев, связанных с отсутствием данных и кода, которые были вытеснены в UMA память (такие аппаратные сбои приводят к аварийному отключению питания с основных аппаратных компонентов платформы). С другой стороны применение этих методов позволяет осуществить DoS-атаки на технологию AMT в случае ее применения для удаленного управления.

Видеозапись доклада опубликована на сайте PHDays — нужно найти в списке выступление под названием «How to Become the Sole Owner of Your PC».
Поделиться с друзьями
-->

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


  1. Jeditobe
    31.05.2016 16:27

    Буквально на днях изучали, как включить. АМТ https://habrahabr.ru/post/283146/

    Вопрос на посыпку, если у меня ноут на Атоме, там это есть? И насколько оно выключено, если следов не наблюдается?


    1. Arqwer
      31.05.2016 18:56

      На сколько я понял, то 1. всё происходит в чипсете поэтому наличие не зависит от процессора. 2. чтобы найти следы их нужно очень внимательно искать. На чипсете Q35 часть кода AMT выполняется, даже если AMT выключен в биосе.


      1. dartraiden
        31.05.2016 22:26

        Логично, поскольку AMT это такой «приятный бонус» от наличия ME. Если пользователь не хочет сам удалённо управлять своим железом — он волен отключить, но, увы, Intel не намерена лишать такой возможности себя.


    1. dartraiden
      31.05.2016 22:20

      AMT у вас нет. Но практически гарантированно есть IME.

      Небольшой ликбез: https://geektimes.ru/company/intel/blog/274186/#comment_9174636

      Очень упрощённо: AMT это «рычаги» ME, доступные конечному потребителю. Они доступны на чипсетах с приставкой Q. А ME есть во всех интеловских чипсетах, независимо от того, доступны ли пользователю какие-либо настройки.


      1. Jeditobe
        31.05.2016 22:22

        А зачем оно там есть? И можно ли до него как-то достучаться?


        1. dartraiden
          31.05.2016 22:32
          +2

          Например, чтобы исполнять Java-апплеты, подписанные корпорацией Intel.
          Причём, даже без необходимости загружать основную ОС («работает даже тогда, когда компьютер выключен (но электропитание подаётся)» — https://habrahabr.ru/company/dsec/blog/282546/), поскольку там своя RTOS прошита.

          Достучаться в каком смысле? Использовать самому его возможности для удалённого управления — только на Q-чипсетах. Удалить — при удалении блоба из прошивки чипсет осуществляет принудительные перезагрузки.

          Можно ещё почитать https://habrahabr.ru/company/dsec/blog/278549/ и https://habrahabr.ru/company/dsec/blog/282546/
          В целом, всё грустно — современное железо неподконтрольно владельцу.


        1. dartraiden
          31.05.2016 22:38
          +2

          Вот ещё интересный комментарий о том, что осуществляет ME
          https://habrahabr.ru/company/dsec/blog/282546/#comment_8872410

          Увы, самые вкусные вещи Intel прячет под NDA (договор о неразглашении).


  1. flothrone
    31.05.2016 22:23
    +6

    Технология 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-контроллер не подаётся питание? Или подлинно известно, что он перестаёт исполнять код (например, халтится)?


    1. xvilka
      01.06.2016 12:02
      +1

      Просто записать рандомные данные на ME раздел. Если компьютер будет работать больше 30 минут — то да, это значит ME отключен. Всё остальное — не показатель. Есть один момент, правда, часть функциональности ME придется добавлять в system firmware (UEFI/coreboot).


    1. d_olex
      01.06.2016 14:13
      +2

      +1
      Наиболее вменяемый юзкейс отключения ME — это выкидывание бинарного блоба ME региона из coreboot и прочих опенсорсных прошивок, что в случае с описанными в статье трюками невозможно (да и не факт что возможно вообще).


    1. ptsecurity
      01.06.2016 17:54
      -1

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

      В презентации об этом сказано, сам Intel допускает определенную фривольность (видимо исторический фактор).

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

      В «живой природе» выловить такое не удалось, видимо это вопрос времени,
      но патент и настройки для этой функции в Flash Image Tool для PCH есть
      уже сейчас.

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

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

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

      • либо приводят к DoS всей платформы;
      • либо являются запросом к подсистеме Intel ME на отключение самой себя.

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

      Тут есть несколько тонких моментов:

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

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

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

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

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

      Что касается KVM, то это было сделано всего лишь для наглядности, мы не опираемся на это как на главный довод.

      >Неужели на ME-контроллер не подаётся питание? Или подлинно известно,
      что он перестаёт исполнять код (например, халтится)?

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


      1. flothrone
        01.06.2016 22:20
        +1

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


  1. gonzzza
    01.06.2016 00:29
    +1

    Много разговоров в последнее время на эту тему. Я и сам озаботился данным вопросом после появления на лаптопе важных рабочих файлов. Более всего, конечно, пугает минимум существующей информации и отсутсвие даже намеков на надежное рабочее решение проблемы, ни програмное ни хардварное…


  1. suntexnik
    01.06.2016 06:49

    Пора переходить на Open Hardware…
    Какая там конфигурация компа у Столлмана?


    1. pftbest
      01.06.2016 10:26

      Если кратко то можно пользоваться компьютерами с процессором Intel не младше 2009 года и компьютерами с AMD не младше 2012 года. Из ноутбуков хорошо поддерживаются ThinkPad'ы T400 и X200. Более подробно можно почитать по этой ссылке https://libreboot.org/faq/#intelbastards


      1. Frankenstine
        02.06.2016 15:06

        Вы хотели сказать наоборот — не старше 2009 года для интел и 2013 для АМД.


        1. pftbest
          02.06.2016 15:16

          Нет, я вроде все правильно сказал, старые Core 2 Duo можно использовать, а современные молодые Core i7 уже нельзя.


          1. Frankenstine
            02.06.2016 15:30

            Вы сказали же

            можно пользоваться компьютерами с процессором Intel не младше 2009 года


            1. pftbest
              02.06.2016 15:46

              Я вижу что я написал, но я не могу понять что вам не нравится. Может путаются понятия больше/меньше старше/младше? Если процессор 2008 года то он ведь старше процессора 2015 года, то есть попадает в категорию не младше?


              1. DjOnline
                08.06.2016 01:07

                Весь мир вокруг думает по другому. Не младше 2009 года в голове 99% означает «вышло после 2009 года», а не «вышло до 2009 года», поэтому правильнее писать «не старше». Вернее правильней писать (чтобы поняло большинство) «процессоры не старше 2009 года выпуска». Дело в том, что если в предложении встречается год, то мозг человека применяет слова «младше/старше» именно применительно к году в виде синонимов «раньше/позже», даже если там нет ключевого слова «года выпуска».


          1. rrpv
            03.06.2016 23:47

            >старые Core 2 Duo можно использовать, а современные молодые Core i7 уже нельзя.

            Уточните пожалуйста, почему разделение происходит именно так, и по процессорам, а не по материнским платам/чипсетам.

            Вопрос задаю потому-что те же самые платы на Q35 работали с процессорами уровня Core 2 Duo.


            1. flothrone
              04.06.2016 00:06

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

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


            1. pftbest
              04.06.2016 00:38

              Так написано в документации libreboot, по ссылке что я привел в первом посте. Вот цитата:

              Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include «ME Ingition» firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.


              1. flothrone
                04.06.2016 00:59

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

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

                Начиная с 6.x версии, когда ME стал обязательным компонентом, вырезать ME регион не потеряв работоспособности системы уже не так просто.


    1. xvilka
      01.06.2016 12:06

      См TALOS на OpenPOWER. Ну и lowRISC SoC.


  1. Arqwer
    01.06.2016 13:38

    А софтверные механизмы защиты памяти помогают от этого дела? Вроде как я слышал, что в Linux адресация памяти перемешана каким-то очень хитрым образом, чтобы нельзя было угадать, какой адрес где физически находится. Или это всё равно не спасает?
    Может ли система хотя бы в теории зашифровать сама себя так, чтобы intel ME даже имея доступ к памяти не смог ничего подсмотреть?


    1. MacIn
      01.06.2016 23:40

      Вроде как я слышал, что в Linux адресация памяти перемешана каким-то очень хитрым образом, чтобы нельзя было угадать, какой адрес где физически находится. Или это всё равно не спасает?

      ASLR есть и в Windows, от 7 версии. Если какой-то код подгружается и исполняется до/независимо от ОС, ничего не спасет.


  1. Arqwer
    01.06.2016 13:46
    +1

    Получается, что любой хакер, получивший приватный ключ интела может превратить все компьютеры в один большой ботнет, а заодно контролировать все финансовые потоки включая криптовалюты, подделать результаты президентских выборов? Если не это всевластие, то что?


    1. Jeditobe
      01.06.2016 14:47

      Такой сценарий уже не невозможен. Это точно.