Comments 56
Достаточно сказать, что Intel ME является единственной средой исполнения, которая имеет внеполосный доступ к сетевому интерфейсу
вероятно, это справедливо при использовании mac из состава pch. или это и для pci-e сетевых справедливо?
на большинстве consumer платформ второй вариант, ибо phy от intel стоит больше pci-e mac+phy от того же relatek
Кроме повышения безопасности, какие негативные моменты с точки зрения функционала вызовет отключение данной системы. Такие фишки как WOL, включение по нажатию клавиши, я так понимаю работать не будут?
Хороший вопрос. Да, не будут функционировать некоторые ACPI функции (которые повесили на ME), управление кулерами, ICC (управление частостами и разгон), программный TPM 2.0 и некоторые прикладные технологии Intel (в духе IPT) работать не будут. Точнее можно сказать для конкретной модели ПК, изучив состав кодовых модулей в прошивке Intel ME.
Всё, что жизненно необходимо компьютерной системе требуется реализовать в BIOS.
На всякий случай отмечу: обработкой function-кнопок на ноутах (уровень яркости экрана, громкость, подсветка, тачпад и прочее) занимается ACPI Embedded Controller (EC), а не ME. Следовательно, эта функциональность не пропадёт.
Всё, что жизненно необходимо компьютерной системе требуется реализовать в BIOS.
На всякий случай отмечу: обработкой function-кнопок на ноутах (уровень яркости экрана, громкость, подсветка, тачпад и прочее) занимается ACPI Embedded Controller (EC), а не ME. Следовательно, эта функциональность не пропадёт.
Не будет оверклокинга и управления частотой пользователем (ICC), могут быть проблемы с воспроизведением защищенного DRM контента (PAVP), перестанут работать выполняемые МЕ Java-апплеты (DAL, они очень редки и в живой природе практически не встречаются), в общем, всего того, что использует интерфейс HECI. Есть еще некоторые другие, более серьезные, но NDA не позволяет говорить о них ничего конкретного.
Одно могу сказать — проблем с отключенным МЕ прилично и бороться с ними непросто, но пока это единственный способ иметь ReadOnly-прошивку, которая требуется банковской сфере, операторам игровых автоматов, промышленным автоматизаторами другим клиентам, которым требуется железная гарантия отсутсвия любых изменений в ПО системы.
Одно могу сказать — проблем с отключенным МЕ прилично и бороться с ними непросто, но пока это единственный способ иметь ReadOnly-прошивку, которая требуется банковской сфере, операторам игровых автоматов, промышленным автоматизаторами другим клиентам, которым требуется железная гарантия отсутсвия любых изменений в ПО системы.
Исходя из практики использования IT систем, можно сказать что вариант отключения ME подходит только для закрытых систем, то есть систем создаваемых с 0 и с конечным перечнем фирменного софта, рассчитанного на отсутствие ME.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.
В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
Лучший способ — избегать использования систем с МЕ (и PSP), других хороших способов защититься от МЕ, имеющего доступ к внутренней шине DMI и собственный DMA-контролер с обходом IOMMU просто нет.
Уже не раз писал, но повторюсь: цель информационной безопасности не в закрытии уязвимостей, а в том, чтобы сделать получение несанкционированного доступа к информации дороже самой информации. Если у вас совершенно секретные данные — делайте себе процессоры сами, на своих фабриках и со своей архитектурой. Не имеете возможности или желания — придется доверять компаниям Intel и/или AMD, стратегическим партнерам АНБ. Можно еще надеяться на успех проектов вроде LowRISC/OpenRISC, но, как показывает случай Сноудена (сильно ускоривший внедрение повсеместного E2E-шифрования), пока в ME/PSP не найдут заяющую дыру, деньги в открытое железо никто вкладывать не будет и ситуация с ME сильно не изменится.
Уже не раз писал, но повторюсь: цель информационной безопасности не в закрытии уязвимостей, а в том, чтобы сделать получение несанкционированного доступа к информации дороже самой информации. Если у вас совершенно секретные данные — делайте себе процессоры сами, на своих фабриках и со своей архитектурой. Не имеете возможности или желания — придется доверять компаниям Intel и/или AMD, стратегическим партнерам АНБ. Можно еще надеяться на успех проектов вроде LowRISC/OpenRISC, но, как показывает случай Сноудена (сильно ускоривший внедрение повсеместного E2E-шифрования), пока в ME/PSP не найдут заяющую дыру, деньги в открытое железо никто вкладывать не будет и ситуация с ME сильно не изменится.
Способ-то, положим, простой: не выставлять сетевой интерфейс компьютера в открытую сеть.
А у Amd есть закладки вроде intel me?
Есть, но пока еще не во всех чипсетах, а только в SoC. Это PSP, который является ядром ARM с TrustZone и используется для HVB, реализации программного TPM 2.0, ускорения криптографических операций, а в последних поколениях Falcon SoC он уже и память тренирует, и S3 resume выполняет, так что платформа теперь без PSP фактически неработоспособна. При этом его прошивка зашифрована и подписана ключем AMD, что там в ней происходит — не знает практически никто, в том числе и потому, что машин AMD на рынке кот наплакал, и заниматься их реверсом почти никому не интересно.
Про PSP я, кстати, уже писал, почитайте, если интересно.
Про PSP я, кстати, уже писал, почитайте, если интересно.
У них есть AMD Platform Security Processor (PDF-презентация).
могут быть проблемы с воспроизведением защищенного DRM контента
вероятно, только при использовании интегрированного видео
ещё, вероятно, с iommu возникнут проблемы на платформах, где оно есть
Правильно ли я понимаю, что проекты вроде https://libreboot.org/ или https://www.coreboot.org/ ни в коей мере не влияют на работоспособность ME?
Цель проекта LibreBoot — полностью свободная прошивка без сторонних бинарных компонентов, поэтому с чипсетами новее 5 серии он не совместмим. Проект CoreBoot использует сторонние компоненты вроде ME firmware или VBIOS, поэтому на работоспособность ME практически не влияет. Я пишу «практически» потому, что для инициализации интерфейса HECI используются UEFI DXE-драйверы, которые в CereBoot нужно еще портировать, чтобы с ME можно было общаться из ОС.
UFO just landed and posted this here
Например, обновить BIOS, ..., изменить настройки BIOS
Это как раз может FPT, упомянутый в статье.
UFO just landed and posted this here
Прошивки 7.x и 8.x совместимы в плане апдейта. Вроде это единственный случай, когда можно обновить прошивку Intel ME на версию следующей major version.
У них одинаковые открытые ключи RSA, которые используются для верификации кода в прошивке (подробнее про защиту от модификаций прошивки Intel ME можно прочитать в моей предыдущей статье).
Поэтому, вероятно, у вас платформа какой-нибудь последней ревизии, и вендор начал пихать туда ME firmware поновее. А может вы обновляли BIOS, и в образ входила новая версия ME firmware.
У них одинаковые открытые ключи RSA, которые используются для верификации кода в прошивке (подробнее про защиту от модификаций прошивки Intel ME можно прочитать в моей предыдущей статье).
Поэтому, вероятно, у вас платформа какой-нибудь последней ревизии, и вендор начал пихать туда ME firmware поновее. А может вы обновляли BIOS, и в образ входила новая версия ME firmware.
Совместимы они только для чипсетов седьмой серии начиная со степпинга B3, поэтому просто так обновлять 7.x на 8.x не стоит — не всегда срабатывает. Если производитель уже обновил за вас — молодец, значит, сам чипсет и platform support code готовы работать с версиями 8.x, а если нет — рисковать не стоит.
Я так полагаю, использование сетевых адаптеров (занять usb или pci-e слот), особенно с какими-нибудь экзотическими чипсетами, значительно понизит вероятность утечки информации или удаленного управления компьютером?
p.s. как страшно жить… что по поводу ARM SoC? Там правда тоже блобов предостаточно, но если закрыть глаза про экзотическую периферию и видеоускоритель, на открытом коде вполне рабочее.
p.s. как страшно жить… что по поводу ARM SoC? Там правда тоже блобов предостаточно, но если закрыть глаза про экзотическую периферию и видеоускоритель, на открытом коде вполне рабочее.
А можно ли, наоборот, включить vPro там где он заблокирован? Есть Lenovo t420s, процессор i5-2520m и чипсет qm67, vPro наличествует, но не работает. Когда-то к нам везли ноутбуки у которых был заблокирован по законодательным причинам AES (!!!) и модуль TPM, возможно, что vPro не работает по причине как-то связанной с блокировкой TPM. Очень уж хочется попробовать этот самый mei.
Полный реверс-инженеринг, очевидно. И гигантский посыл ненависти интелу.
И главное не забывать что Intel это стратегический партнер АНБ
У меня пара вопросов. Наверное это скорее в отношении серверов. Если поставить машину за файрволом, и фильтровать все что идет к/от МЕ, то это снимет угрозу?
И более интересный вопрос. Если вообще не пользоваться Ethernet, то не врубится ли на борде какой-нибудь вай-фай или блютус? Никто не проверял МЕ(чипсет) на предмет собственного встроенного беспроводного интерфейса?
А то ведь если очень надо какой-то закрытой компании, то можно не пользоваться обычного рода сетями, а эмулировать на ПЛИС+PCI что-то вроде проприетарной сети, а серверы брать обычные на x86/AMD64. И тогда встает вопрос об отстутствии «чего-то еще сетевого» на матери.
И более интересный вопрос. Если вообще не пользоваться Ethernet, то не врубится ли на борде какой-нибудь вай-фай или блютус? Никто не проверял МЕ(чипсет) на предмет собственного встроенного беспроводного интерфейса?
А то ведь если очень надо какой-то закрытой компании, то можно не пользоваться обычного рода сетями, а эмулировать на ПЛИС+PCI что-то вроде проприетарной сети, а серверы брать обычные на x86/AMD64. И тогда встает вопрос об отстутствии «чего-то еще сетевого» на матери.
Могу сказать что с 100 серии появилась встроенная поддержка NFC в Intel ME — http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-1.pdf 40 страница
Размещение компьютера с ME за файервол, на котором настроена фильтрация запросов к ME по признакам (список портов которые я привёл, это лишь один из признаков, поэтому чтобы выявить все признаки, нужно хорошенько покопать в эту сторону) минимизирует attack surface по сети через Ethernet. Не более и не менее.
У ME есть и другая периферия (немного подробнее, в моей предыдущей статье).
И да, вы правильно мыслите, есть ещё доступ к WiFi, начиная с версии 2.5 (правда там своя специфика, в частности определённая модель сетевой карты). Но эта возможность развивалась.
К тому же, как отмечено в комментарии выше, с недавних пор появилась поддержка NFC. Единственное, добавлю, что поддержка определённой модели NFC-адаптера появилась кажется в 8 или 9 серии чипсетов. А 100 серии возможность была расширена.
У ME есть и другая периферия (немного подробнее, в моей предыдущей статье).
И да, вы правильно мыслите, есть ещё доступ к WiFi, начиная с версии 2.5 (правда там своя специфика, в частности определённая модель сетевой карты). Но эта возможность развивалась.
К тому же, как отмечено в комментарии выше, с недавних пор появилась поддержка NFC. Единственное, добавлю, что поддержка определённой модели NFC-адаптера появилась кажется в 8 или 9 серии чипсетов. А 100 серии возможность была расширена.
Для доступа к Wi-Fi, как я понимаю, он физически должен быть либо в составе матери, либо отдельной карточкой. И это видно и понятно. На серьезных серверных бордах его просто нет.
Но вот с NFC — это просто волшебно. :) Интересно, как это обосновывается с точки зрения удаленного администрирования?? :) Там же максимальное расстояние для связи всего несколько см… Ну хорошо… до 20см. И где базируется этот самый NFC? Там же в чипсете? У меня только единственная мысль, что возможно ME через него слушает эфир? И не факт, что только в пределах своих 13,56 МГц. Какой-то достаточно мощный сигнал. Ну и ждет какую-то сигнатуру, как спусковой крючок для темных делишек.
Кстати, а эта область UMA ME доступна из режима SMM? А то ведь можно ее таким образом пофиксить. Конечно уже после загрузки, но какая разница когда…
Но вот с NFC — это просто волшебно. :) Интересно, как это обосновывается с точки зрения удаленного администрирования?? :) Там же максимальное расстояние для связи всего несколько см… Ну хорошо… до 20см. И где базируется этот самый NFC? Там же в чипсете? У меня только единственная мысль, что возможно ME через него слушает эфир? И не факт, что только в пределах своих 13,56 МГц. Какой-то достаточно мощный сигнал. Ну и ждет какую-то сигнатуру, как спусковой крючок для темных делишек.
Кстати, а эта область UMA ME доступна из режима SMM? А то ведь можно ее таким образом пофиксить. Конечно уже после загрузки, но какая разница когда…
Не доступна. Область эта для CPU выглядит как замапленная на несуществующее PCI-устройство, сплошные 0xFF, которые не получается переписать. Стартует ME значительно раньше процессора по power sequence, и вообще может сделать все свои темные дела до reset vector'а, так что никакие фиксы со стороны кода, выполняемого на CPU, не помогут.
Про Wi-Fi вы верно написали.
NFC, насколько я могу судить, является частью технологии Intel IPT (Identity Protrection Technology). Посмотрите здесь.
Область ME UMA, после инициализации BIOS-ом, залочивания и сообщения о DRAM init done через MEI к ME-контроллеру (и только после этого ME-контроллер начнёт её использовать) недоступна CPU ни в каких-режимах.
NFC, насколько я могу судить, является частью технологии Intel IPT (Identity Protrection Technology). Посмотрите здесь.
Область ME UMA, после инициализации BIOS-ом, залочивания и сообщения о DRAM init done через MEI к ME-контроллеру (и только после этого ME-контроллер начнёт её использовать) недоступна CPU ни в каких-режимах.
OK. Но если BIOS выделил и залочил UMA для ME, то какой режим для этого использовался? Почему нельзя зайти в тот же режим и разлочить эту область? Есть ли что-то вообще почитать, как UMA выделяется?
По сути, не важно что там делал ME до загрузки. По-моему, важно его хотя бы после деактивировать.
И есть ли где-то дизасемблированный код ME для последних ревизий, когда он уже на x86? Интересно посмотреть, что он там вообще делает.
По сути, не важно что там делал ME до загрузки. По-моему, важно его хотя бы после деактивировать.
И есть ли где-то дизасемблированный код ME для последних ревизий, когда он уже на x86? Интересно посмотреть, что он там вообще делает.
Самый обычный режим, после блокировки, эта память не должна быть доступна CPU в любом случае. Почитать нет, есть только поревёрсить — начать следует с ранних этапов работы BIOS.
Чтобы поревёрсить код ME пользуйтесь программками для распаковки кодовых модулей из прошивки Intel ME (ссылки в статье, во введении) + дизассемблер, разумеется.
Чтобы поревёрсить код ME пользуйтесь программками для распаковки кодовых модулей из прошивки Intel ME (ссылки в статье, во введении) + дизассемблер, разумеется.
Возможно этого расстояния будет достаточно для общения с другими устройствами внутри системного блока. Таким способом можно будет пробросить Ethernet любому другому устройству внутри системника через NFC. Например, добавили новый SSD или просто флешку воткнули… Этакий Plug&Play через NFC+Ethernet в Интернет, например.
При этом фаерволл должен быть на железке гарантированно без ME. Ану как МЕ, имея внеполосный доступ ко всем гнездам эзернета, увидя запросы своих братьев сам пробрасывает их дальше? Этакий не контролируемый ботнет. Есть повод задуматься.
А как ME получает ip адрес? Обычным образом просится к открытому dhcp? И mac адрес у него свой собственный или совпадает с основным?
Подскажите, а есть ли PoC-exploit демонстрирующий возможность злонамеренного использования ME?
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
Единственные открыто доступные описание и PoC для исполнения кода на Intel ME применяемы только на чипсете Q35.
Здесь Intel ME используется для циклической записи в разные участки оперативной памяти компьютера обычной текстовой строки.
Если хотите поэкспериментаровать с этим PoC, лучше найти где-нибудь МП Intel DQ35JO/DQ35JOE или DQ35MP/DQ35MPE.
Здесь Intel ME используется для циклической записи в разные участки оперативной памяти компьютера обычной текстовой строки.
Если хотите поэкспериментаровать с этим PoC, лучше найти где-нибудь МП Intel DQ35JO/DQ35JOE или DQ35MP/DQ35MPE.
Ещё вспомнил про этих ребят. Они этот PoC, на который я привёл ссылку выше развили и сделали кейлоггер, управляемый командами по сети.
UFO just landed and posted this here
А это вообще есть на Apple? По крайней мере, не замечал, чтобы у меня в эппловской сети регистрировались какие-то посторонние mac адреса.
Intel ME есть в абсолютно всех выпускаемых на данный момент чипсетах/SoC от Intel.
Так что, продукция Apple, на которой используются чипсеты и процессоры Intel, — не исключение.
Если, AMT (хотя я не видел, чтобы у Apple девайсов была оф. поддержка Intel vPro) не включена, по идее ME не должен лезть в сеть. По идее.
Так что, продукция Apple, на которой используются чипсеты и процессоры Intel, — не исключение.
Если, AMT (хотя я не видел, чтобы у Apple девайсов была оф. поддержка Intel vPro) не включена, по идее ME не должен лезть в сеть. По идее.
UFO just landed and posted this here
Apple никаких инструментов для работы с МЕ из OSX не предоставляет, а больше и некому. Насколько я успел понять, у Apple есть доступ к исходному коду ME, и потому на их системах прошивка сильно обрезана и не публикует интерфейс HECI, а то и вообще отключается после начальной инициализации, но тестовой машины у меня нет, так что судить не берусь.
Интересно, что мешает внешнему файрволу реализованному на аналогичном аппаратном обеспечении по-братски пропустить AMT-запрос?
А под линукс утилит управления ME/AMT нет?
Насчёт стандартных утилит/драйверов для ОС: у Windows они входят в комплект ПО Intel ME, предоставляемый компанией Intel или распространяемый вендором компьютерой системы. Для Linux точно ответить не смогу, но, проведя аналогию, предполагаю, что они есть в драйверах от Intel.
Специальных утилит для Linux от Intel для работы с AMT (например, ACUwizard, который я упоминал в статье) я не знаю, но, на крайняк, есть Intel AMT SDK.
Linux-версий утилит из System Tool Kit (для работы с образами флеш-памяти и с подсистемой Intel ME) нет, но, почти для всех утилит рядом лежат DOS-версии. Замечу, что не имеющие DOS-версий утилиты не используют интерфейс HECI, просто работая с образами прошивок, поэтому их можно запустить на виртуалке.
Специальных утилит для Linux от Intel для работы с AMT (например, ACUwizard, который я упоминал в статье) я не знаю, но, на крайняк, есть Intel AMT SDK.
Linux-версий утилит из System Tool Kit (для работы с образами флеш-памяти и с подсистемой Intel ME) нет, но, почти для всех утилит рядом лежат DOS-версии. Замечу, что не имеющие DOS-версий утилиты не используют интерфейс HECI, просто работая с образами прошивок, поэтому их можно запустить на виртуалке.
Sign up to leave a comment.
Intel ME. Как избежать восстания машин?