В предыдущей статье был описан ход исследования безопасности прошивок промышленных коммутаторов. Мы показали, что обнаруженные архитектурные недостатки позволяют легко подделывать образы прошивок, обновлять ими свитчи и исполнять свой код на них (а в некоторых случаях — и на подключающихся к свитчам клиентах). В дополнение, мы описали возможности закрепления внедряемого кода на устройствах. Подчеркнули низкое качество кода прошивок и отсутствие механизмов защиты от эксплуатации бинарных уязвимостей.
Мы обещали привести реальный пример сильной модели безопасности прошивок, где модификация исполнимого кода является очень нетривиальной задачей для потенциального злоумышленника.
Встречайте – подсистема Intel Management Engine, самая загадочная составляющая архитектуры современных x86-платформ.
Введение
Для начала, основательно разберёмся в предметной области. Что это такое, откуда и зачем появилось?
В 2005 году компания Intel представила Active Management Technology (AMT) версии 1.0 — решение для удалённого администрирования (управление, инвентаризация, обновление, диагностика, устранение неполадок и т.д.) и защиты десткопных компьютерных систем, своего рода аналог технологии Intelligent Platform Management Interface (IPMI), использующейся в серверах.
[рисунок взят отсюда]
Архитектура AMT 1.0 основывается на интегрированном в чипсет микроконтроллере (Management Engine), наделённому весьма впечатляющими возможностями, например:
- внеполосный (out-of-band) доступ к сетевому интерфейсу (Ethernet), который он разделяет с основным CPU, но, имея собственный контроллер канального уровня, осуществляет мониторинг всего входящего сетевого трафика, из которого «вырезает» (при помощи Packet Filter) пакеты, предназначенные для него. Для ОС (наличие и состояние которой, кстати, на работу AMT никак не влияет) этот трафик уже не виден;
- внутренний веб-сервер с TLS-шифрованием;
- доступ к периферийному оборудованию, получение и хранение в энергонезависимой памяти (там же, где и его прошивка) информации о нём.
А ещё этот микроконтроллер начинает работать при подаче питания на материнскую плату компьютерной системы (т.е. при подключении компьютера к электрической сети, ещё до того, как пользователь нажмёт кнопку Power).
Итак, Management Engine всегда включён, но использование возможностей AMT требует активации (подразумевает задание пароля, сетевых параметров,… ) в BIOS setup, а точнее в MEBx setup:
[скриншот взят отсюда]
Похвально, что дефолтный пароль («admin») при первом входе обязательно требуется изменить на новый, удовлетворяющий определённым требованиям: минимум 8 символов, среди которых должны присутствовать хотя бы одна цифра, одна заглавная буква и один спец. символ.
После настройки AMT-совместимой компьютерной системы, удалённому администратору
становятся доступными сетевые функции (для их использования требуется ввод логина и пароля):
- инвентаризация аппаратного обеспечения;
- веб-интерфейс (по HTTP через порт 16992);
- Serial Over LAN (SOL) – виртуальный COM-порт через сеть, позволяющий включать/перезагружать/выключать компьютер, получать доступ к меню BIOS setup;
- IDE-Redirection (IDE-R) – опция перенаправления загрузки с локального загрузочного устройства на удалённое (предварительно подготовленный образ системы).
AMT 1.0 была реализована на интегрированном в южный мост чипсета (Input/Output Controller Hub, ICH) сетевом модуле Intel 82573E series Gigabit Ethernet Controller.
Затем, в 2006 году, начиная с AMT версии 2.0, микроконтроллер перенесли в северный мост чипсета (Graphics and Memory Controller Hub, GMCH). Именно тогда подсистему наименовали в Intel Management Engine (ME) версии 2.0.
[рисунок взят отсюда]
Одновременно с этим появился бренд Intel vPro, который обозначал комплекс реализованных на основе Intel ME технологий: AMT, Trusted Execution Technology (TXT) и Virtualization Technology (VT). Позже в этот список вошли Identity Protection Technology (IPT) и Anti-Theft (AT).
Тогда же Intel ME наделили ещё большим количеством впечатляющих возможностей, среди которых — полный доступ ко всему содержимому оперативной памяти компьютера через внутренний DMA-контроллер, а в дальнейшем появилась возможность мониторинга видеопотока, выводящегося на монитор (правда, только в случае использования встроенного графического ядра).
Постепенно на эту подсистему стали навешивать всё больше различных системных функций (некоторыми раньше занимался BIOS) для обеспечения работоспособности компьютерной платформы:
- часть функций Advanced Control and Power Interface (ACPI) и Alert Standard Format (ASF);
- Quiet System Technology (QST);
- Integrated Clock Control (ICC);
- Trusted Platform Module (TPM);
- ...
и других технологий.
AMT тоже не стояла на месте и активно развивалась: изменялся состав используемых протоколов (например, добавилась поддержка HTTPS через порт 16993), в версии 6.0 для удалённого администратора появилась фича Remote Desktop, она же KVM (Keyboard Video Mouse), и прочее.
Подробнее про развитие Intel AMT можно почитать здесь.
Тем не менее, из-за высокой стоимости реализации, эта подсистема присутствовала, за несколькими исключениями, только на материнских платах с чипсетами Intel линейки Q:
| GMCH | ICH | ME/AMT version |
|---|---|---|
| Q965 | ICH8 | ME 2.x (AMT 2.x) |
| GM965 / GME965 / GL960 / GLE960 / PM965 | ICH8M | ME 2.5.x (AMT 2.5.x) < — первое появление на ноутбуках |
| Q35 | ICH9 | ME 3.x (AMT 3.x) |
| GM45 / PM45 | ICH9M | ME 4.x (AMT 4.x) < — только на ноутбуках |
| Q45 | ICH10 | ME 5.x (AMT 5.x) |
Тогда к чему вся эта специфика железа с шильдиком vPro, которое мало кто (в РФ) приобретал ввиду высокой стоимости (ну и других причин)?
Дело в том, что, начиная с 2010 года, вместе с переносом части функциональных блоков северного моста (графическое ядро, контроллер памяти, ...) в корпус CPU, подсистему Intel ME стали встраивать во все чипсеты производства Intel. При этом ME-контроллер остался в корпусе чипсета – в Platform Controller Hub (PCH). Это чипсеты 5 серии и выше.
Итак, хронология последующих версий для десктопов и лаптопов:
| PCH | ME/AMT version |
|---|---|
| 5 series chipset | ME 6.x (AMT 6.x) |
| 6 series chipset | ME 7.x (AMT 7.x) |
| 7 series chipset | ME 8.x (AMT 8.x) |
| 8 series chipset | ME 9.x (AMT 9.x) |
| 9 series chipset | ME 9.5.x/10.x (AMT 9.5.x/10.x) |
| 100 series chipset | ME 11.x (AMT 11.x) |
Примечание: функциональность AMT по сей день остаётся доступной только на чипсетах линейки Q, т.е. только на оборудовании с шильдиком vPro.
Думаете только десктопы и ноутбуки? Нет, Intel-а ответ!
Та же участь постигла и серверные платформы от Intel: подсистема встроена в них, но под другим именем — Intel Server Platform Services (SPS). Произошло появление и в SoC (System-on-a-Chip) под именем Intel Trusted Execution Engine (TXE).
В итоге архитектура каждой современной мобильной/лаптопной/дескопной/серверной компьютерной платформы с чипсетом/SoC от Intel включает в себя самую скрытную (от пользователя системы) и привилегированную среду исполнения — подсистему Intel ME. Неудивительно, что разрабатывая эту архитектуру, компания Intel была вынуждена серьёзно поработать над её защитой от компрометации.
Вздохнём и рассмотрим архитектуру этой подсистемы, чтобы разобраться в применённой модели безопасности. Вдруг это поможет успокоиться?
Архитектура Intel ME
Intel Management Engine (ME) – встроенная в компьютерные платформы подсистема, обеспечивающая аппаратно-программную поддержку различных технологий Intel.
Как уже было сказано, первые версии этой подсистемы были основаны на двухкорпусных чипсетах Intel. Тогда в качестве базовой модели ME-контроллера использовался ARCtangent-A4 со стандартной системой команд ARC32.
[рисунок взят из книги 1]
В однокорпусных чипсетах уже использовались ARCtangent-A5/ARC600 с компактной системой команд ARCompact (ARC16/32).
[рисунок взят из книги 1]
В Intel SoC (там где эта подсистема называется Intel TXE) в качестве базовой модели для ME-контроллера используется SPARC.
ARC-и, SPARC-и какие-то, да? Ревёрсить некомфортно будет!
Ничего страшного, в Intel об этом позаботились: в самых последних платформах (Skylake, чипсеты 100 серии, Intel ME 11.x) ME-контроллер имеет архитектуру… x86!
Да-да, в чипсетах теперь живёт ещё один x86.
Впрочем, состав компонентов подсистемы Intel ME (с версии 2.0) не изменялся. Это:
- ME-контроллер – встроенный в чипсет 32-разрядный микроконтроллер типа RISC, имеющий внутренние ROM и SRAM;
- Регион ME в SPI флэш-памяти, в котором хранится разработанная и подписанная компанией Intel прошивка ME-контроллера (поэтому, именно Intel ME firmware);
- ME UMA – скрытая ото всех, кроме ME-контроллера, область (16 — 32 МБ) в оперативной памяти компьютера, которой он пользуется в качестве runtime-memory для размещения и запуска прошивки;
- Management Engine Interface (MEI), ранее известный как Host Embedded Controller Interface (HECI), – набор регистров в конфигурационном пространстве PCI и область в MMIO, представляющие собой интерфейс для обмена информацией с ME-контроллером (по сути, единственный канал связи софта, исполняющегося на CPU, с подсистемой Intel ME);
- Отдельный MAC – контроллер канального уровня, предоставляющий ME-контроллеру out-of-band доступ к общему физическому сетевому интерфейсу для удалённого администрирования компьютерной системой;
- Некоторые модули в BIOS, отвечающие за инициализацию платформы и сообщающие о результатах своей работы ME-контроллеру через MEI.
В случае наличия шильдика Intel vPro, в состав подсистемы Intel ME дополнительно входит BIOS-модуль ME BIOS Extenstion (MEBx), предоставляющий графический интерфейс (показан выше), а также осуществляющий включение и конфигурирование AMT через MEI.
Таким образом, у нас имеется среда исполнения ring -3 (так её условно называют) — 1 штука. Её привилегированность обуславливается способностями, которыми наделён ME-контроллер (о них написано выше), а скрытность — полным отсутствием возможности контроллировать программными (и даже аппаратными, в production-версиях плат) средствами.
Архитектура ME-контроллера
Внутри ME-контроллера, помимо микропроцессора ARC/SPARC/x86:
- ME ROM – энергонезависимая неперезаписываемая память, в которой хранится стартовый код ME-контроллера;
- ME SRAM – оперативная память используемая ME-контроллером при недоступности ME UMA, например, на ранних этапах работы;
- кэш кода и кэш данных, для повышения производительности при работе с памятью;
- C-Link (Controller Link) – шина, позволяющая ME-контроллеру взаимодействовать с периферийным аппаратным обеспечением в режимах S5 (System shutdown) / S3 (Sleep mode);
- Различные аппаратные блоки:
- высокоточный таймер и WDT;
- контроллер прерываний;
- контроллеры памяти и DMA;
- интерфейс HECI/MEI;
- RNG, акселлератор криптографических функций и функций сжатия.
[рисунок взят из книги 2]
Самое время разобраться в том, как от модификаций защищён код, который управляет всем этим богатством.
Прошивка Intel ME
Intel ME firmware, в зависимости от наполнения, различают двух типов:
- 1.5 МБ, урезанные версии;
- 5 МБ, полные версии.
Тип прошивки определяет состав прикладных модулей, в которых реализованы определённые технологии (например, AMT, IPT и т.д.). Хотя есть и базовая часть, одинаковая для разных прошивок:
- Bring Up, первый запускаемый модуль из прошивки;
- Kernel, ядро ОСРВ ThreadX;
- Некоторые драйверы и службы.
Общее описание содержимого Intel ME firmware можно найти в книге 2 из списка литературы, но детальнее со структурами (разобраны аналитическим путём) можно ознакомиться, например, в этом скрипте для распаковки прошивок Intel ME.
Пойдём по порядку.
В SPI флэш-памяти есть несколько регионов:
- Flash Descriptors, в котором хранятся указатели на все остальные регионы, а также read/write привилегии для пользователей этой памяти. Отметим, что обычно этими дескприпторами запрещается перезапись ME региона всем, за исключением самого ME-контроллера;
- GbE (Gigabit Ethernet);
- ME, здесь хранится прошивка ME-контроллера;
- BIOS;
- 3PDS (Third Party Data Storage), опциональный регион.
[картинка взята отсюда]
Теперь взглянем на сам регион ME, вот пример содержимого из его начала:
Это Flash Partition Table (FPT) — таблица разделов ME firmware. В ней хранятся указатели на различного типа (код, данные, виртуальная область, ...) разделы и их параметры. Целостность этой таблицы контролируется одним байтом чексуммы по смещению 1Bh.
Нас интересуют executable-разделы, т.е. те, что хранят исполнимый код. Их обычно несколько, рассмотрим один из них:
В начале кодового раздела располагается манифест, который состоит из заголовка (со служебными данными и ЭЦП) и таблицы модулей.
В приведённом дампе можно увидеть 2048-битный открытый RSA ключ (модуль по смещению 80h относительно начала раздела и экспонента по смещению 180h). Далее следует 256 байт сигнатуры.
Своим закрытым ключом компания Intel подписывает часть заголовка манифеста и таблицу модулей (см. следующий дамп), прикладывая полученную подпись и открытый ключ для проверки.
А вот и фрагмент таблицы модулей рассматриваемого раздела:
Эта таблица содержит заголовки модулей, где указаны некоторые параметры и хеш-сумма SHA256 (по смещению 14h внутри заголовка).
Сгенерировать собственную пару ключей RSA-2048 и подписать ими раздел не получится ввиду того, что целостность приложенного открытого ключа проверяется стартовым кодом в ME ROM, в котором хранится хеш-сумма SHA256 открытого ключа компании Intel.
В итоге, схему верификации кодового раздела ME firmware можно обобщить на рисунке:
Каждый кодовый раздел верифицируется по этой схеме.
Этого более чем достаточно для защиты прошивки от подделывания. Программно перезаписать ME регион SPI флеш-памяти нельзя (помним про разрешения в Flash Descriptors), аппаратные средства, конечно позволят обойти это ограничение, но контроль подлинности не выключить.
Напоследок, посмотрим в сторону защиты от бинарных уязвимостей.
Мы увидели, что весь исполнимый код ME firmware разбит на модули разного назначения:
[рисунок взят из книги 1]
У ME-контроллера есть два режима работы: привилегированный и пользовательский (аналоги kernel mode и user mode для CPU). Привилегированный режим отличает, прежде всего, возможность доступа к аппаратным ресурсам и возможность обращения по адресам вне отведённого этому модулю диапазона памяти.
Каждый модуль запускается и работает в заданном (в заголовке этого модуля) режиме.
[рисунок взят из книги 1]
Распарсив весь ME регион можно увидеть, что привилегированный режим используется ядром ОСРВ и некоторыми драверами. Службам и прикладными модулям, как и положено, отводится только пользовательский режим.
Заключение
Мы показали, что подсистема Intel ME является неотъемлемой частью архитектуры современных компьютерных платформ (на основе чипсетов/SoC Intel). Очевидно, что её компрометация предоставляет потенциальному злоумышленнику безграничные возможности контроля над платформой: доступ ко всему содержимому оперативной памяти (системная память, память гипервизора, SMRAM, ACRAM, выделяемая память для графического ядра — GFX UMA), out-of-band доступ к сетевому интерфейсу (мониторинг всего сетевого трафика), удалённый контроль как часть штатной функциональности AMT, перезапись любых регионов SPI флеш-памяти. Бонусом к этому является полное отсутствие возможностей обнаружения.
Это является веской причиной для наличия у Intel ME серьёзной защиты. Мы считаем, что вендоры любого встраиваемого сетевого оборудования должны стремиться к описанной модели безопасности. Её характеризуют следующие принципы:
- запрет на использование дефолтного пароля, принуждение к установке сильного пароля (соответствующего определённым требованиям);
- использование функций шифрования в сетевых протоколах;
- контроль целостности и подлинности всего исполнимого кода прошивки;
- механизмы защиты от эксплуатации бинарных уязвимостей.
Заранее прокомментирую возможные призывы использовать компьютерные платформы на основе CPU и чипсетов от AMD: у них есть очень похожая технология, называется Platform Security Processor (PSP). Представлена не так давно, в 2013 году. Про неё пока известно не много, но кое-что можно почитать здесь.
Список литературы
1. A. Kumar, «Active Platform Management Demystified: Unleashing the Power of Intel VPro (TM) Technology», 2009, Intel Press.
2. Xiaoyu Ruan, «Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine», 2014, APress.
Комментарии (41)
Dshuffin
04.03.2016 10:41+1А какие возможности ME доступны для не vPro материнок?
CodeRush
04.03.2016 11:03+5- Integrated Clock Control (управление частотами и разгон)
- Firmware TPM (программный TPM 2.0, появился недавно)
- Protected Audio-Video Path (защита медиаконтента от перехвата во время просмотра, DRM в общем)
- Dynamic Application Loader (загрузка и исполнение подписанных Intel Java-апплетов)
Все остальное — зависит от OEM, кто-то покупает еще модулей, а кто-то старается от DAL и PAVP избавиться.
Никакие возможности MEBx и удаленного администрирования декларируются недоступными для Consumer-вариантов ME, но что там по факту — знают 3,5 специалиста из Intel.
flothrone
04.03.2016 12:04+1Добавлю, что у многих vPro- и не-vPro материнок абсолютно одинаковые регионы ME)
Например, на плате с чипсетами Qx и Hx.
Таким образом, реализация той же AMT присутствует даже там, где нет шильдика vPro. Но на не-vPro платформе не хватает другого важного компонента: инциализируещего AMT кода из MEBx.
Dshuffin
04.03.2016 18:10+1А почему драйвер для ME не опубликован на сайте интел, и его нужно скачивать с сайта производителя материнки? Есть тому какая-то причина?
CodeRush
04.03.2016 20:07+1Т.к. именно OEM решает, какие модули поставлять, вместе с этим решается и вопрос с драйверами. Кто-то поставляет минимальный драйвер heci.sys на пару десятков килобайт, а кто-то другой — полный пакет с софтом и службами для поддержки PAVP и DAL.
Для своих плат Intel выкладывает пакет драйверов для МЕ, вот, к примеру для NUC.
merlin-vrn
04.03.2016 11:21+1Классный обзор, перечитаю ещё раз. Пока что один вопрос: а чем это принципиально отличается от идеи IPMI? Вроде бы, такая же идея, ME по сути — BMC?
CodeRush
04.03.2016 11:33+2Принципиально — уровнем интеграции. Карту IPMI можно вынуть или отключить от питания, BMC выпаять с платы и выпатчить его инициализацию из прошивки, а здесь приходится либо мириться с тем, что МЕ есть и будет есть, либо платить Intel кучу денег за его отключение, которое все равно не совсем полное.
merlin-vrn
04.03.2016 11:44+1Надо было мне перед тем, как спрашивать, почитать вики. А там написано, что "IPMI используется инициативой Intel AMT". IPMI это интерфейс взаимодействия с BMC (как самой системы, так и OOB), а ME, похоже, конкретная реализация BMC.
А про выпилить — ну а скажите, можно ли iDRAC выпилить (совсем, с корнями), или iLO?CodeRush
04.03.2016 11:51+2Все, что не находится прямо на чипе, можно выпилить при наличии сильного желания, пары хороших специалистов и некоторого количества времени. В данном же случае для двухчиповых решений для избавления от МЕ придется разрабатывать собственный PCH, а для SoC — смиряться и получать удовольствие. В конце концов, можно купить сервер на Intel Xeon без iDRAC и iLO, а вот без ME — уже нет.
flothrone
04.03.2016 11:59+4Спасибо. Не совсем, хотя на первый взгляд, очень похоже, особенно в ранних версиях.
Во-первых, поддержку спефикации IPMI может реализовывать (причём и аппаратную, и программную часть) не только Intel, а ещё ряд вендоров. Например, у HP есть iLO, у Dell — iDRAC. В случае с ME происходит lock in на вендора.
Но правильнее, на мой взгляд, сравнивать IPMI с возможностями AMT. Хотя технологии преследуют разные цели:
- AMT — полный «захват» управления над удалённым компьютером для дминистрирования. Говоря простым языком: ОС переустановить, от вирусов вылечить, файрвол настроить, настройки в BIOS setup поменять и прочее;
- IPMI — стандарт подчинения серверами ряду команд для удобства управления (причём даже не столько управления сколько мониторинга за состоянием: крутятся вентиляторы, ничего не отвалилось/сожглось и т.п.).
Во-вторых, разница в архитектуре существенная. BMC — это, прежде всего, отдельная микросхема (рядом которой есть ещё одна одтельная микросхема которая хранит BMC firmware) не наделённая такими возможностями как ME (доступ к содержимому оперативной памяти, видеопотоку… ).
Хотя, в самых первых версиях у Intel подсистема ME использовалась в качестве BMC в серверных платформах. Это был ICH Intel 631xESB / 632xESB (ESB2), если не ошибаюсь.
Говоря о разнице, хочется отметить, что ничего не мешает этим технологиям (ME и BMC) сосуществовать вместе на одной серверной платформе. Так много где, в тех же цисках (с чипсетами Intel, разумеется).
en1gma
04.03.2016 11:34+1если я правильно понял, то первая версия не особо описана в разделе "архитектура" и там описание со второй версии.
в первой версии всё амт"шное "железо" находилось во внешнем eth-mac. или всё же в mac в южнике? а то схема и текст отличаются.
есть ли возможность установить плату расширения с 82573E и побаловаться на произвольном компе с амт? интересно всё же, да и без опасности залочить "южник".flothrone
04.03.2016 12:34Всё верно.
ME v1.0 был интегрирован именно в южный мост чипсета. Я думаю, авторы этой картинки (не я рисовал) хотели показать связь через SMBus.
Хотя могу заблуждаться.
alfatapok
04.03.2016 12:33+1Подскажите, где можно узнать о настройке данной подсистемы?
flothrone
04.03.2016 12:36Подсистемы Intel ME?
Её не нужно настраивать, она сама по себе работает)
Если вы про другое, то, пожалуйста, конкретизируйте вопрос.alfatapok
04.03.2016 18:51После настройки AMT-совместимой компьютерной системы, удалённому администратору
становятся доступными сетевые функции (для их использования требуется ввод логина и пароля)
я про это. И раз есть MEBx setup, то значит и есть возможность вносить какие-либо изсенения в настройки
Andrey_Perelygin
04.03.2016 12:37+3Спасибо за статью.
Конечно, новость о невозможности на сегодняшний эксплойтов для IME радует, но несколько озадачивает тот факт, что бэкдор для спец. служб все же может существовать, либо может быть создан в любой момент автоматическим апдейтом прошивки.
И ведь подобные системы низкоуровневого удаленного доступа к аппаратной части не только на платформах Intel и AMD.
Сейчас в основном юзаю лэптоп от Lenovo на платформе Intel 8 series и терзают меня тревожные сомнения, что помимо этого низкоуровнего троянчика от Intel, у меня еще и от Lenovo присутствует масса забавных программных решений.
Отсюда встает риторический вопрос: реально ли на сегодняшний день найти железо, в безопасности которого ты сможешь быть уверен на 100%…CodeRush
04.03.2016 12:43+3Моветон, наверное, отвечать на риторические вопросы, но скорее всего правильный ответ — нет.
С другой стороны, задача ИБ — не в том, чтобы быть уверенным на 100%, а в том, чтобы сделать получение информации дороже самой информации. Т.е. если нужно обрабатывать что-то совершенно секретное — лучше разрабатывать и производить все вычислительные устройства самостоятельно на своих мощностях, а если нужно читать твиттер и постить котиков — подойдет железо с любыми бэкдорами, которые этому не мешают.Andrey_Perelygin
04.03.2016 12:58+3Да, с Вашей позицией спорить не приходится, но все же идеи истинного хакинга, хактивизма, свободы…
Думаю, что тут каждый имеет в некотором количестве информацию и, возможно, область деятельности, для которых подобного рода бэкдоры (давайте, все же, называть вещи своими именами) могут нанести колоссальный вред.
С другой стороны, а кто представляет ИБ? Intel? Защита от ребят из анонимус — может быть. Но в случае постановки вопроса о гос. безопасности вся ИБ летит куда подальше. Ну а далее полученные данные может приобрести кто угодно, будь то корпорация, выкупившая напрямую эту информацию у спец. служб или очередной незаурядный школьник, сумевший хакнуть сети гос. учреждений.
Да и опять же, сам Intel может собирать эти данные, как это делают Google, Apple, Microsoft and etc. в своих продуктах.
А если обращать внимание на то, как меняется/изменился мир в сторону всемогущества корпораций и отхождения роли государств на второй план, то очевидно, что точка невозврата пройдена и нас не ждет ничего хорошего.
Но это уже больше банальная лирика, понятная многимCodeRush
04.03.2016 13:16+10Идеи хактивизма и свободы — они отличные, но очень мало кто хочет за них бороться. Единицы говорят о том, что состояние стоит читать вредным, десятки задумываются о том, что закрытую платформу без возможности аудита её пользователем вообще не стоит считать сколько-нибудь "своей" или "безопасной", сотни готовы покупать полностью открытые продукты даже если за это придется заплатить и деньгами, и доступными возможностями, и временем на настройку. При этом миллионы идут в walled garden совершенно добровольно, покупают себе смартфоны, которые следят за ними 24/7/365, устанавливают Windows 10, встраивают чужой дырявый код в лампочки и дверные замки — в общем, издеваются над самой идеей информационной безопасности, анонимности, свободы и всего остального, и индустрия ориентируется именно на них, ибо им можно продать что угодно, если завернуть это в красивую обертку и рассказать, что в этом сезоне это модно.
Я помню времена, когда скандалом была любая программа, которая "звонила домой". Прошло 10 лет, и теперь "домой" звонят даже пуговицы на "умной" одежде, а обычный вроде-бы телефон обладает таким количеством датчиков и такой вычислительной мощностью, что его можно смело использовать как полетный контролер для ракет средней дальности. При этом все вокруг радостно приветствуют такой прогресс. Вот такая вот лирика, от которой хочется матом разговаривать.Andrey_Perelygin
04.03.2016 13:23+2Вопрос что делать нам, людям, которые так или иначе находятся в сердце IT мира. Уничтожают собственным оружием, так сказать.
CodeRush
04.03.2016 13:32+6Бороться, писать статьи, поддерживать разработчиков открытого железа (LowRISC, OpenRISC, MIPS, даже Quark и Minnowboard от Intel, которые "открытее", чем все остальное) финансово и информационно, свести к минимуму использование закрытых продуктов, в общем — голосовать ногами. Либо расслабиться и попытаться получить удовольствие от процесса, утешая себя тем, что "честным людям скрывать нечего", "кому я нужен, такой незначительный" и т.п.
PavelMSTU
05.03.2016 22:17+2Есть OpenSource, а должно появиться аналогичное для железа… Правда в первые n-цеть лет качество железа будет не очень…
Но и Linux не сразу стал гегемоном...
flothrone
04.03.2016 12:47+1Благодарю.
Да, мысли правильные) вполне возможно, что есть. Такую технологию спецслужбам оставить без внимания — не верю.
CodeRush
04.03.2016 12:51+1Добавлю, что у Lenovo это скорее всего Computrace (удаленное управление и блокировка) и WPBT (ACPI-таблица для запуска хранящегося в прошивке кода после установки или переустановки Windows). Если укажете конкретную модель — могу посмотреть и сказать точнее.
Andrey_Perelygin
04.03.2016 13:11Lenovo y50-70. Весь предустановленный софт на SHD снес, поставил арч.
CodeRush
04.03.2016 13:46+1Посмотрел, ничего особенного. WPBT поддерживается, но самой таблицы в прошивке нет, только драйвер для нее, используется устаревший интерфейс IHISI при наличии более нового UEFI Capsule, т.е. обладая инженерными утилитами Insyde можно прошить вредоносный код, следов Computrace/LoJack я не нашел, BootGuard/BiosGuard тоже отключены. Плюс видна защита от повреждения S3 BootScript'а и NVRAM, так что общий уровень защиты прошивки я бы оценил как "выше среднего", если смотреть только по бинарю.
Andrey_Perelygin
04.03.2016 13:50+1Благодарю за консультацию. У Вас не найдется под рукой ссылки, где стоит поискать кастомную безопасную прошивку?
CodeRush
04.03.2016 14:17+2Только самому собирать. Coreboot для этих машин недоступен, насколько я знаю, а из UEFI можно удалить лишнее, используя UEFITool и программатор. Если интересно, посмотрите мое выступление на ZeroNights2015 и слайды к нему, я там как раз рассказывал о модификации прошивки ноутбука с Insyde H2O.
xvilka
04.03.2016 13:59+4Желающим покопаться во внутренностях — рекомендую эти две утилиты для распаковки ME прошивки на модули https://io.smashthestack.org/me/ и https://github.com/skochinsky/me-tools
Ivan_83
04.03.2016 21:39+1Значит остаётся амд и элбрус без бэкдоров?
CodeRush
04.03.2016 21:59+2Ничего не скажу про Эльбрус, т.к. не в курсе, но у AMD даже в системах без PSP достаточно закрытых компонентов, которые имеют доступ к внутренностям SoC. К примеру, контролеру XHCI нужна бинарная прошивка, т.к. он был приобретен у строннего поставщика IP-ядер, система управления частотами и питанием (SMU) сделана на контролере Lattice и тоже имеет бинарную закрытую прошивку, в которой уже находили уязвимости, встроенный EC тоже нуждается в бинарной прошивке, и так далее.
По факту, на x86 уже давно толком ничего не остается, и если вас не связывает с этой архитектурой груз обратной совместимости, то лучше свои безопасные системы делать на какой-нибудь более другой.
flothrone
11.03.2016 11:17Есть ещё варианты платформ, которые подойдут в случае, если не волнует обратная совместимость с x86: Power8, Talos, Novena.
Очень интересный проект Purism.
IvanIDSolutions
05.03.2016 13:38+2Хрология = хронология, исправьте под-ста! Материал очень интересный, спасибо!
CodeRush
Отличная обзорная статья, спасибо.
Рад, что с 2009 года никаких серьезных уязвимостей в МЕ не нашли, спасибо SeCoE за это. С другой стороны, грустно, что приходится слепо доверять неизвестному коду, имеющему слишком большие привилегии и при этом наглухо закрытому даже от анализа.
Если вам не нравятся процессоры с подобными "подсистемами обеспечения безопасности" — у AMD еще есть десктопные процессоры без PSP, а вот последним ноутбучным было семейство eKabini, все более новые SoC серии Falcon — уже даже память через PSP тренируют и S3 resume им же делают, так что там теперь еще большее болото, чем с ME у Intel.
flothrone
Благодарю