В начале 2017-го года Максим Малютин (Maksim Malyutin) из компании Embedi обнаружил уязвимость в Intel AMT, которая была официально оглашена Intel первого мая и получила номер CVE-2017-5689 (INTEL-SA-00075 в кодификации Intel). Уязвимости был присвоен тип «повышение прав» (Elevation of Privilege) и критический уровень опасности. Многие СМИ в ответ разразились заголовками что-то типа «серверные чипсеты Intel 9 лет имели уязвимость», видимо отталкиваясь от фразы «This vulnerability does not exist on Intel-based consumer PCs» в описании. Однако это не совсем так с переходом в совсем не так. Потому далее подробное техническое описание уязвимости, её реализация и, главное, способы защиты для систем, не имеющих обновления прошивки.
Без углубления в подробности что такое технология Intel Active Management Technology (AMT), всё же, нужно отметить, что не стоит путать Intel ME и Intel AMT, т.к. AMT всего лишь один из модулей (условно говоря — плагин), работающий на «движке» Intel ME. Мажорная версия Intel ME меняется с каждым поколением процессоров, вместе с ней, меняется и мажорная версия Intel AMT. Затронуты уязвимостью все версии начиная с Intel AMT 6 (соответственно Intel ME 6 и выше) — вплоть до самых новых (Intel ME 11.6 на момент написания статьи).
Также нужно добавить, что Intel Standard Manageability (ISM) — это урезанная версия Intel AMT (с ограниченным функционалом, но это AMT), а вот Intel Small Business Technology (SBT) — это технология, которая использует функционал AMT для своей работы (неточное определение но в общем смысл такой), но ею никак не является (это другой, отдельный плагин в составе движка Intel ME).
Для поддержки Intel AMT требуется наличие трёх составляющих:
Только наличие всех трёх даёт полноценную поддержку Intel AMT. Грубо (без совсем старых и деления на мобильные/десктоп) чипсеты Intel можно поделить на:
Технологию Intel AMT поддерживают лишь чипсеты из 3-го и 5-го пункта, а технологию Intel SBT из 2-го — только этих сегментов касается уязвимость CVE-2017-5689. Если же уточнить, то из-за «непрямого» отношения SBT к AMT 2-й пункт рассматривать можно лишь условно, а поддерживающий на уровне чипсета 5-й пункт обычно отпадает, т.к. серверные чипсеты рассчитаны на использование BMC-контроллеров для удалённого управления, в многом дублируя функционал Intel AMT (или наоборот), потому реализовывать и поддержку BMC и поддержку AMT в BIOS вендоры особенно не спешат, в то время как для поддержки Intel AMT требуется и поддержка всех трёх условий (см. выше).
Соответственно, почти всегда в случае наличия Intel AMT речь будет идти лишь о чипсетах Qxx.
В системах SoC (System on Chip — когда процессор и чипсет интегрированы) узнать поддержку AMT сложней, т.к. это зависит от конкретной модели. В общем случае процессоры, поддерживающие Intel AMT можно найти на ark.intel.com/ru/Search/Advanced?ExtendedPageTables=True, выбрав в самом низу галку «Intel vPro Technology» (но также стоит не забывать про требования поддержки в BIOS).
Уязвимостью можно воспользоваться:
Во всех случаях требуется, чтобы технология AMT уже была проинициализирована/сконфигурирована.
Отдельной неприятной вещью является тот факт, что несконфигурированный компьютер, начиная с Intel AMT версии 7 и выше можно программно проинициализировать локально в клиентский режим (т.е. даже из расконфигурированного состояния). Потому в рекомендациях от Intel по борьбе с уязвимостью CVE-2017-5689, кроме различных телодвижений из разряда «всё выключить» есть опциональные «Disable CCM» — отключить клиентский режим и «Disable HBE» — отключить автоматическую инициализацию AMT (неприменимо для обычных компьютеров-ноутбуков — это лишь для встраиваемых систем). Потому как с помощью данных возможностей, предназначенных для упрощения программной инициализации, эту процедуру можно сделать на любой системе с поддержкой AMT (исключение — запрещённое AMT в BIOS).
Все подробности нахождения уязвимости указаны в первоисточнике, они сделаны на примере Intel AMT 9 системы. Если коротко, то была дизассемблированная часть, обрабатывающая запросы к встроенному в Intel AMT web-серверу по характерным заголовкам (username, realm, nonce и т.д.) процесса аутентификации:
При исследовании на выходе функции проверки авторизации (заголовок «Authorization»), где сравниваются пароли (переданный с установленным) был обнаружен код проверки пароля:
В результате получается, что в третий аргумент для функции strncmp() — количество сравниваемых символов, загружается длина из нашего ответа, а значит, при нулевом значении strncmp всегда будет давать true.
Понятно, что это ошибка разработчика, который должен был указать в качестве проверяемой длины пароля не длину передаваемого авторизующимся юзером (который можно сделать любым, в т.ч. передать значение нулевой длины), а установленного (админского) пароля.
В документе от Embedi был описан простой вариант с локальным доступом при сконфигурированном AMT без использования TLS — когда используется AMT-порт 16992. Чтобы не повторяться, будет приведён другой случай — доступ к расположенному в локальной сети компьютеру с поддержкой AMT, сконфигурированному на использование TLS (т.е. через AMT-порт 16993).
Подключаемся к системе с поддержкой AMT (т.к. при подключении по TLS будет проверяться имя сервера, то используется FQDN, а не IP):
Залогиниться со стандартным логином admin и оставив поле пароля пустым не получится (что понятно):
Теперь произведём манипуляцию с HTTP-заголовками, для этого используем расширение для Firefox HttpRequester.
Делаем пробный запрос (данные не важны), чтобы просто узнать realm из ответа (в ошибке в заголовке WWW-Authenticate будет нужный для составления дальнейшего запроса параметр:
Теперь добавляем вручную заголовок «Authorization»:
А в качестве значения указываем полученный ранее realm и следующие параметры:
После чего жмём Add и отправляем запрос.
Нас интересует параметр nonce, который уникален для каждой сессии. Добавляем его в заголовок (для этого придётся удалить старый и добавить новый), должно получиться что-то типа:
С поправкой на каждый раз разный nonce и свой realm.
Сама уязвимость выделена жирным — пустое значение пароля, чтобы после была проверка по его нулевой длине.
Отправляем составленный таким образом (но достаточно быстро — пока не истекла сессиия):
Есть логин, теперь можно открыть страницу в Firefox:
Никаких при этом запросов на пароль не было.
Рекомендации Intel по защите от CVE-2017-5689 в основном заключаются в отключении AMT на поддерживающих её системах. Но, во-первых, многие (например, я) с удовольствием пользуются и хотят пользоваться впредь этой реально удобной технологией удалённого администрирования (особенно освоив её работу через интернет) и потому нет никакого желания отказываться от этого, банально выключая AMT в BIOS. Во-вторых, по опыту прошлых проблем различных вендоров с отключением AMT в BIOS, несложно предположить аналогичные и в будущем — когда отключённая в BIOS технология Intel AMT почему-то работала или могла быть активирована (несмотря на «Disabled» в BIOS Setup). Зная это, всегда наиболее правильной рекомендацией является проинициализовать и правильно настроить AMT — как раз для защиты систем с поддержкой Intel AMT (в противоположность «отключить и/или расконфигурировать»). В правильную настройку в том числе входит использование сертификатов для аутентификации (в дополнение к парольной) — сколько уж говорилось про ненадёжность парольной защиты, глупо повторяться.
Для этого можно использовать различные утилиты, например, официальный Manageability Commander от Intel (или другой удобной, я предпочитаю MeshCommander).
(На «Invalid TLS» обращать внимания не стоит, т.к. используется самоподписанный сертификат)
Закрываем доступ для не-TLS соединений и включаем клиентскую аутентификацию и для локального (через LMS) и для удалённого доступа (по сети и интернету), предварительно создав и загрузив нужные сертификаты.
Теперь при попытке зайти сначала (до парольной уязвимости) будет запрос на сертификат:
И только предоставив корректный сертификат, хэш рута которого был предварительно добавлен в хранилище сертификатов AMT данного компьютера и DNS которого был прописан в списке разрешённых — будет получен доступ к системе. Где уже дальше будет запрос на пароль (подвержённый уязвимости).
Таким образом AMT-система будет защищена и её можно привычно пользоваться, даже если обновление прошивки с исправлением уязвимости CVE-2017-5689 так и не будет выпущено производителем вашей системы.
Ссылки:
Intel ME, AMT, ISM, SBT
Без углубления в подробности что такое технология Intel Active Management Technology (AMT), всё же, нужно отметить, что не стоит путать Intel ME и Intel AMT, т.к. AMT всего лишь один из модулей (условно говоря — плагин), работающий на «движке» Intel ME. Мажорная версия Intel ME меняется с каждым поколением процессоров, вместе с ней, меняется и мажорная версия Intel AMT. Затронуты уязвимостью все версии начиная с Intel AMT 6 (соответственно Intel ME 6 и выше) — вплоть до самых новых (Intel ME 11.6 на момент написания статьи).
Также нужно добавить, что Intel Standard Manageability (ISM) — это урезанная версия Intel AMT (с ограниченным функционалом, но это AMT), а вот Intel Small Business Technology (SBT) — это технология, которая использует функционал AMT для своей работы (неточное определение но в общем смысл такой), но ею никак не является (это другой, отдельный плагин в составе движка Intel ME).
Hardware
Для поддержки Intel AMT требуется наличие трёх составляющих:
- Поддержка AMT в чипсете
- Поддержка AMT в процессоре
- Поддержка поддержка AMT в BIOS
Только наличие всех трёх даёт полноценную поддержку Intel AMT. Грубо (без совсем старых и деления на мобильные/десктоп) чипсеты Intel можно поделить на:
- Обычные — чипсеты Hxx и Zxx
- Малый бизнес — чипсеты с Bxx
- Бизнес/Корпоратив — чипсеты Qxx
- «Для энтузиастов» — чипсеты Xxx
- Серверные — чипсеты C2xx
Технологию Intel AMT поддерживают лишь чипсеты из 3-го и 5-го пункта, а технологию Intel SBT из 2-го — только этих сегментов касается уязвимость CVE-2017-5689. Если же уточнить, то из-за «непрямого» отношения SBT к AMT 2-й пункт рассматривать можно лишь условно, а поддерживающий на уровне чипсета 5-й пункт обычно отпадает, т.к. серверные чипсеты рассчитаны на использование BMC-контроллеров для удалённого управления, в многом дублируя функционал Intel AMT (или наоборот), потому реализовывать и поддержку BMC и поддержку AMT в BIOS вендоры особенно не спешат, в то время как для поддержки Intel AMT требуется и поддержка всех трёх условий (см. выше).
Соответственно, почти всегда в случае наличия Intel AMT речь будет идти лишь о чипсетах Qxx.
В системах SoC (System on Chip — когда процессор и чипсет интегрированы) узнать поддержку AMT сложней, т.к. это зависит от конкретной модели. В общем случае процессоры, поддерживающие Intel AMT можно найти на ark.intel.com/ru/Search/Advanced?ExtendedPageTables=True, выбрав в самом низу галку «Intel vPro Technology» (но также стоит не забывать про требования поддержки в BIOS).
Доступ
Уязвимостью можно воспользоваться:
- Локально на AMT-компьютере — требуется наличие установленных драйверов AMT, в частности драйвера LMS
- В локальной сети — firewall при этом не защищает, т.к. технология AMT перехватывает трафик ДО его обработки ОС. Кроме того, компьютер может быть вообще выключен (но подключён к сети+электросети)
- По интернету — в случае того, если компьютер был настроен на работу AMT через Intel MPS (плюс ранее указанное в пункте 2)
Во всех случаях требуется, чтобы технология AMT уже была проинициализирована/сконфигурирована.
Отдельной неприятной вещью является тот факт, что несконфигурированный компьютер, начиная с Intel AMT версии 7 и выше можно программно проинициализировать локально в клиентский режим (т.е. даже из расконфигурированного состояния). Потому в рекомендациях от Intel по борьбе с уязвимостью CVE-2017-5689, кроме различных телодвижений из разряда «всё выключить» есть опциональные «Disable CCM» — отключить клиентский режим и «Disable HBE» — отключить автоматическую инициализацию AMT (неприменимо для обычных компьютеров-ноутбуков — это лишь для встраиваемых систем). Потому как с помощью данных возможностей, предназначенных для упрощения программной инициализации, эту процедуру можно сделать на любой системе с поддержкой AMT (исключение — запрещённое AMT в BIOS).
Дизассемблирование
Все подробности нахождения уязвимости указаны в первоисточнике, они сделаны на примере Intel AMT 9 системы. Если коротко, то была дизассемблированная часть, обрабатывающая запросы к встроенному в Intel AMT web-серверу по характерным заголовкам (username, realm, nonce и т.д.) процесса аутентификации:
При исследовании на выходе функции проверки авторизации (заголовок «Authorization»), где сравниваются пароли (переданный с установленным) был обнаружен код проверки пароля:
ld r1, [sp:user_response+10ch]; проверяемый пароль > в регистр r1 (второй аргумент strncmp)
mov r0, r13 ; АМТ-пароль > в регистр r0 (первый аргумент strncmp)
ld r2, [sp:a4h] ; длина проверяемого пароля > в регистр r2 (третий аргумент strncmp)
bl strncmp ; call strncmp()В результате получается, что в третий аргумент для функции strncmp() — количество сравниваемых символов, загружается длина из нашего ответа, а значит, при нулевом значении strncmp всегда будет давать true.
Понятно, что это ошибка разработчика, который должен был указать в качестве проверяемой длины пароля не длину передаваемого авторизующимся юзером (который можно сделать любым, в т.ч. передать значение нулевой длины), а установленного (админского) пароля.
Практическая проверка уязвимости AMT-систем
В документе от Embedi был описан простой вариант с локальным доступом при сконфигурированном AMT без использования TLS — когда используется AMT-порт 16992. Чтобы не повторяться, будет приведён другой случай — доступ к расположенному в локальной сети компьютеру с поддержкой AMT, сконфигурированному на использование TLS (т.е. через AMT-порт 16993).
Подключаемся к системе с поддержкой AMT (т.к. при подключении по TLS будет проверяться имя сервера, то используется FQDN, а не IP):
Залогиниться со стандартным логином admin и оставив поле пароля пустым не получится (что понятно):
Теперь произведём манипуляцию с HTTP-заголовками, для этого используем расширение для Firefox HttpRequester.
Делаем пробный запрос (данные не важны), чтобы просто узнать realm из ответа (в ошибке в заголовке WWW-Authenticate будет нужный для составления дальнейшего запроса параметр:
Теперь добавляем вручную заголовок «Authorization»:
А в качестве значения указываем полученный ранее realm и следующие параметры:
Digest username=«admin», realm=«Digest:EB580000000000000000000000000000», uri="/index.htm", qop=auth, nc=, cnonce="", opaque=""
После чего жмём Add и отправляем запрос.
Нас интересует параметр nonce, который уникален для каждой сессии. Добавляем его в заголовок (для этого придётся удалить старый и добавить новый), должно получиться что-то типа:
Digest username=«admin», realm=«Digest:EB580000000000000000000000000000», nonce=«dh8jcw1CAQCTmvMOLG5UghjzJper6NvS», uri="/index.htm", qop=auth, nc=, cnonce="", response="", opaque=""
С поправкой на каждый раз разный nonce и свой realm.
Сама уязвимость выделена жирным — пустое значение пароля, чтобы после была проверка по его нулевой длине.
Отправляем составленный таким образом (но достаточно быстро — пока не истекла сессиия):
Есть логин, теперь можно открыть страницу в Firefox:
Никаких при этом запросов на пароль не было.
Защита действующих AMT-систем (с ошибкой CVE-2017-5689 в firmware) с помощью настройки аутентификации по сертификату (mutual auth)
Рекомендации Intel по защите от CVE-2017-5689 в основном заключаются в отключении AMT на поддерживающих её системах. Но, во-первых, многие (например, я) с удовольствием пользуются и хотят пользоваться впредь этой реально удобной технологией удалённого администрирования (особенно освоив её работу через интернет) и потому нет никакого желания отказываться от этого, банально выключая AMT в BIOS. Во-вторых, по опыту прошлых проблем различных вендоров с отключением AMT в BIOS, несложно предположить аналогичные и в будущем — когда отключённая в BIOS технология Intel AMT почему-то работала или могла быть активирована (несмотря на «Disabled» в BIOS Setup). Зная это, всегда наиболее правильной рекомендацией является проинициализовать и правильно настроить AMT — как раз для защиты систем с поддержкой Intel AMT (в противоположность «отключить и/или расконфигурировать»). В правильную настройку в том числе входит использование сертификатов для аутентификации (в дополнение к парольной) — сколько уж говорилось про ненадёжность парольной защиты, глупо повторяться.
Для этого можно использовать различные утилиты, например, официальный Manageability Commander от Intel (или другой удобной, я предпочитаю MeshCommander).
(На «Invalid TLS» обращать внимания не стоит, т.к. используется самоподписанный сертификат)
Закрываем доступ для не-TLS соединений и включаем клиентскую аутентификацию и для локального (через LMS) и для удалённого доступа (по сети и интернету), предварительно создав и загрузив нужные сертификаты.
Теперь при попытке зайти сначала (до парольной уязвимости) будет запрос на сертификат:
И только предоставив корректный сертификат, хэш рута которого был предварительно добавлен в хранилище сертификатов AMT данного компьютера и DNS которого был прописан в списке разрешённых — будет получен доступ к системе. Где уже дальше будет запрос на пароль (подвержённый уязвимости).
Таким образом AMT-система будет защищена и её можно привычно пользоваться, даже если обновление прошивки с исправлением уязвимости CVE-2017-5689 так и не будет выпущено производителем вашей системы.
Ссылки:
Поделиться с друзьями
dartraiden
Так всё же, подвержены ли этой уязвимости «десктопные» платы, где AMT не поддерживется?
Вот тут товарищ утверждает, что интеловская утилита заявила, что его плата на чипсете H97 уязвима. Я подозреваю, что утилита ориентируется лишь на версию Intel ME, не глядя на то, доступна ли AMT.
apple_rom
В статье указано грубое деление чипсетов, где Intel SBT подразумевается у настольных чипсетов B77 и выше.
Размер модуля SBT в Intel ME в разы меньше модуля AMT, потому требования много меньше (и, например, на мобильных он мог быть практически с любым чипсетом). В попытках пристроить технологии «для малого бизнеса», Intel экспериментировал, пытаясь найти подходящую нишу (как среднее между «корпоративным» и «для обычных пользователей»), что дало на выходе включение SBT (или другое название — Small Business Advantage — SBA) и в настольные чипсеты более новых поколений Hxx, например, из вашей ссылки H97. Потому в этом плане утилита, скорей всего права — найдя в системе возможность использования (не обязательно активированную) технологии Intel SBT — она написала про уязвимость.
Bytes 0-3: SKU/Capabilities
Bit 0 — ME enabled/disabled (1 = Enabled)
Bit 1 — Intel QST FW support (1 = Supported)
Bit 2 — Intel ASF FW support (1 = Supported)
Bit 3 — Intel AMT FW support (1 = Supported)
Bit 4 — Reserved for future capabilities (must be set to “0”).
Bit 5 – Intel SBT FW support (1 = Supported)
Bit 6 – Intel Level III management (1 = Supported)*
7-31 — Reserved for future capabilities (must be set to “0”).
Bytes 4-11: ME FW Version.
Bits 32:47 — ME FW Minor Version.
Bits 48:63 — ME FW Major Version.
Bits 64:79 — ME FW Build Number.
Bits 80:95 — ME FW Hotfix Number.
Note: If ME is disabled then other data cannot be retrieved.
*Level III management is no longer supported beginning in Release 9.0.
icbook
apple_rom
Всё-таки как не повлияло наличие технологии Intel AMT на IPMI, так она (или же её кончина) не повлияет и на RedFish.
Intel AMT поддерживает RMCP (порты 623/664), собственно, это, как поддержка DASH и прочих других признанных промышленных стандартов, было требованием интегрирования в имеющуюся корпоративную инфраструктуру.
RedFish, мне кажется, просто новая инкарнация IPMI (в частности — из-за использования таких морально древних протоколов как RMCP). При чём, не обязательно успешная, как и всё в таком страшно консервативном сегменте, как серверный.
icbook
Существует ли открытый и формализованный алгоритм детектирования AMT на заданной платформе (например, UEFI-протокол с заданным GUID)? Вопрос именно о динамическом детектировании в смысле чтения регистров, служебных полей, таблиц и т.п., а не о проверке модели платы или чипсета по заранее составленной базе данных.
apple_rom
Детект Intel AMT и его возможностей на платформах:
Taciturn
Вопрос не очень по теме — какие вообще сертификаты нормально работают с AMT? Q97, прошивка 9.1.41.3024. Установил сертификат Let's Encrypt. В результате в IE11, Opera 12 всё работает, Firefox 53.0.2, Chrome 57.0.2987.133 — SSL_ERROR_BAD_MAC_ALERT.
apple_rom
TLS 1.0 only. Потому старая Опера и работает, во всех современных принудительно включается неподдерживаемый Intel AMT протокол TLS1.2.
Включить TLS 1.0 в новом Chrome проблематично (если подскажете как — спасибо), а в Firefox в about:config поставьте security.tls.version.max в 1 (единичку).
Однако это касается протокола. Если же речь про вообще решение проблемы с дыркой АМТ, то это два шага — создать и добавить TLS-сертификаты плюс включить mutual:
Taciturn
Спасибо за информацию. Manageability/MeshCommander работают, VNC Viewer Plus тоже подключается.
Именно браузером заходить всё равно не особо полезно — доступный функционал чудовищно ограничен, так что если это ожидаемая проблема, то и ладно — нет смысла понижать безопасность браузера.
apple_rom
Всё верно, вообще этот веб-интерфейс лишь для баловства и демонстрации. Реальное управление через специальные утилиты (самая лучшая с поправкой на условный Small Business — Manageability Commander) или пакеты ПО (Kaseya, Spiceworks etc), которые знают про возможности и требования Intel AMT.
YuriM1983
А функцию проверки сертификата писал тот же программист?
apple_rom
Это другой уровень во всех смыслах данного слова. Можно сравнить с уязвимостью/ошибкой в приложении на PHP и вероятностью уязвимости/ошибки в nginx/Apache.
powerman
Понимаю Вашу мотивацию и нежелание отключать AMT, но наличие такой дыры делает очень вероятным наличие других дыр. Не знаю, есть ли они там на самом деле, была ли эта ошибка следствием трагической случайности или системного подхода "пофиг на безопасность" — но сейчас куча людей набросилась на новый лакомый кусочек в поисках новых дыр… или набросятся, как только эксплуатация этой дыры перестанет приносить достаточные дивиденды. Так что до проведения (желательно — публичного) внешнего аудита безопасности исходников AMT держать системы с доступом к AMT из интернета — значит нарываться на неприятности.
MacIn
Какова же эта мотивация?
apple_rom
Наличие «такой дыры» обозначает всего лишь недостаточное тестирование. А недостаточное тестирование обозначает то, что технология AMT, выражаясь дипломатично, не является «приоритетным направлением» для Intel и давно.
распилрасцвет иосиновый кол под номером CVE-2017-5689закат — вообще, грустная история, достойная отдельной статьи, постараюсь написать, когда будет совсем плохо.powerman
С точки зрения менеджера или админа — да. Потому что оценивается причина, по которой ошибка попала в продакшн.
С точки зрения разработчика — нет, это означает именно то, что написал я. Потому что оценивается причина, по которой такой код вообще попал в репо (был кем-то написан, прошёл чьё-то ревью, и был кем-то смержен в основную ветку). Если написанием кода в столь нежном и критичном месте занимается человек, который способен допустить такую грубую ошибку, и его код проходит ревью (либо ревью вообще не делается для таких критичных кусков кода) — это многое говорит о процессе разработки в целом и отношении к безопасности кода в целом. Такие ошибки в принципе не должны доходить до тестировщиков, если безопасность хоть как-то учитывается при разработке.
willyd
Лучше думать о востребованности/неуловимости этого Джо.
Возможно, не у Вас отличные тест съюты, а — вы просто не нужны белым/черным шапочникам подходящего уровня.
Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.
Так что не скромничайте — жгите дальше про критичность и грубые ошибки…
powerman
> Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.
Просто Вы — романтик. А на практике те разработчики, которые беспокоятся о безопасности, ничего проверять не стали, потому что у них давно поставлены процессы и выработано определённое отношение к коду, при котором такие баги не проходят, а если и проходят, то в настолько неочевидных случаях, что просматривать быстренько код после чтения статьи на хабре бессмысленно. А те разработчики, которые о безопасности особо не задумываются — тоже не побегут ничего проверять, потому что им тупо пофигу.
AlB80
1. длину не передаваемого авторизующимся юзером, а установленного пароля плюс один.
2. длину передаваемого авторизующимся юзером пароля плюс один.
Автор попытался исправить ошибку и сделал свою.
firegurafiku
А ещё правильнее, наверное, было бы использовать в этом случае просто
strcmpи не передавать вообще никакую длину. Нужно же строки целиком сравнивать, а не их подстроки. Интересно, почему программист из Intel так сделал: это «микрооптимизация» такая или иррациональный страх не обнаружить завершающего нуля в конце строки?AlB80
Это слишком неопределённое гадание. Но, раз уж это чистый си, то возможно что у них практикуется выделять память под максимальный размер без завершающего нуля. Если значение короче, то ноль на месте, если максимальное, то неявно. Тогда надо указывать некую константу, максимальный размер пароля.
grossws
Сравнивать строки, полученные по сети с помощью
strcmp— прямой путь к выстрелу в ногу.firegurafiku
Вовсе нет, если при получении фильтровать их них внутренние нулевые байты, после чего добивать строку нулём. Если эти ребята по каким-то причинам не пользовались нуль-терминированными строками, то нужно не
strncmpюзать, а соответствующую функцию из их строковой библиотеки, или хотя быmemcmp.grossws
Да, но эту пачку действий (проверка на наличие NUL, усечение при необходимости и прочие радости) нужно делать в каждом месте, где приходит строка снаружи. И рано или поздно человек в этом месте ошибается. Ошибок этого типа не счесть.
icCE
Можно добавить, что Intel ME скорее всего сделан на Minix 3.
dartraiden
ThreadX там, если верить информации из интернетов.
Архитектурно раньше всё крутилось на ARC, потом сделали 2 ядра x86. В последних версиях добавили снова третье ядро ARC.
icCE
Ну то, что пслд раскопали содержат код из minix 3
We are still unable to build an overall picture of ME, due to Huffman compression of the kernel and syslib code. However, it is possible to analyze TXE (Trusted Execution Engine, the equivalent of ME for Intel Atom CPUs) thanks to the absence of Huffman compression.
In addition, when we looked inside the decompressed vfs module, we encountered the strings “FS: bogus child for forking” and “FS: forking on top of in-use child,” which clearly originate from Minix3 code. It would seem that ME 11 is based on the MINIX 3 OS developed by Andrew Tanenbaum :)
http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html
icCE
Уточнение — это относится к 11 версии.
https://www.youtube.com/watch?v=2_aokrfcoUk&feature=youtu.be&t=52m6s
a1ien_n3t
Что-то асмовский код похож больно на ARM. Как так? внутри интела живет кусочек арма?
grossws
Вроде, ARC должен быть. И, как минимум, у ARM Cortex-M нет r18
a1ien_n3t
У 64 bit'ного ARM Cortex-A есть)
grossws
Для такого девайса Cortex-A довольно странно использовать. Cortex-R ещё может быть, хотя там ситуация с регистрами должна быть похожа на Cortex-A.
VitalKoshalew
Кто-нибудь в курсе, откуда у Embedi незашифрованная прошивка AMT? Я думал, все прошивки AMT всегда идут в зашифрованном виде.
zotia
Есть утилита Unhuffme v2.4 для распаковки/расшифрования части кода Intel ME, которая содержится в прошивке от производителей системной платы.
PS: но это не весь код, необходимый для полноценной работы Intel ME.
Ivan_83
Раз оно обрабатывается до ОС значит и фильтровать это надо раньше — в коммутаторе при помощи ACL.
Ещё бы точно знать что именно.
HiroX
Порты 16992 и 16993 закрыть в коммутаторе и все, имхо.
apple_rom
Если вы их перед этим не пробрасывали, то и закрывать незачем. Технология Intel AMT по дефолту подразумевает локальную сеть (потому за роутером она, что логично, не работает — без его настройки под это).
В случае Intel AMT, сконфигурированной на использование Intel MPS (Manageability Proxy Server) или так называемый режим CIRA (Client Initiated Remote Access) — никакие закрытые порты не помогут (т.к. это исходящий трафик). Однако такая система (сделанная вами или до вас) не будет (напрямую, через веб) подвержена данной уязвимости (с некоторой поправкой на то, что адрес MPS-сервера известен лишь вам), т.к. подключиться к веб-интерфейсу через MPS не получится. Хотя сама дырка останется и теоретически её задействовать можно. Но «коммутаторы» тут точно ни при чём.
willyd
Пока лучшая статья по теме. Остальные были в виде сухих выдержек или панических криков.
Aleksi
Лишнее слово.
Shrike
У меня непатченный bios. Решил проверить ваш способ, настроил ради этого AMT )
Получил real/nonce (кстати, это же можно с первого раза получить, зачем два запроса?), шлем их в заголовке «Authorization», так?
Т.е. типа того:
Authorization: Digest username=«admin», realm=«Digest:B3C97E62E59CB92AB6A6EB26AA4771B1», nonce=«yMMSAAQFAAD3wJyN144HDITgcPb+t53A», uri="/index.htm", qop=auth, nc=, cnonce="", response="", opaque=""
Но проц отвечает редиректом на страницу tokenexp.html
esinev
Мы на основе статьи написали простой bash-скрипт для проверки этой уязвимости (test.sh):
Запускаем первый раз и получаем nonce:
Затем во втором аргументе используем полученный nonce: