Comments 65
«Совпадение? Не думаю» (с) цифра…
Там есть ссылка на тулзу intelmetool, которая должна показать текущее состояние ME. Я попробовал у себя запустить, но ничего не вышло:
kern.alert: grsec: denied use of iopl() by /home/powerman/tmp/coreboot/util/intelmetool/intelmetool[intelmetool:12327] uid/euid:0/0 gid/egid:0/0, parent /bin/zsh[zsh:12020] uid/euid:0/0 gid/egid:0/0Надо полагать, наличие Grsecurity в ядре помешает не только этой тулзе, но и попыткам эксплуатировать ME…?
МЕ работает на самом низком уровне, и на защиту грсека ему накласть.
Безусловно, но ведь до ME сначала надо как-то добраться. И вот добраться до ME grsec помешал.
Вопросы в комментах на хабре задаются как раз тогда, когда времени и/или желания читать первоисточники нет. Я достаточно сильно интересуюсь безопасностью, но всё же не в такой степени, чтобы разбираться в таких вопросах профессионально — у меня и своя работа есть. Так что в данном случае я интересуюсь как обычный обеспокоенный пользователь этих продуктов: каким конкретно образом происходит доступ к ME на моей системе?
Доступ через I/O порты, похоже, заблокирован Grsecurity.
Прямой доступ через физическую память тоже заблокирован Grsecurity (/dev/mem).
Запись в /dev/cpu/*/msr тоже заблокирована Grsecurity.
Остаётся доступ через сеть, когда IPMI/BMC читают и перехватывают пакеты на уровне сетевой карты ещё до того, как их увидит OS (если OS вообще запущена в этот момент).
Есть ещё какие-то варианты помимо вышеупомянутых?
Что касается варианта с доступом через сетевые пакеты — насколько я понимаю, в десктопных материнках, в которых нет IPMI/BMC, это работать не должно (WakeOnLan я обычно в BIOS отключаю, не знаю, имеет ли это отношение к данной ситуации).
Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.
Вот, собственно, то, что мне интересно: работает ли вышеупомянутый "локальный" способ эксплуатации при наличии Grsecurity, и если работает — то через что. Раз возможности удалённо эксплуатировать вроде бы нет, то не похоже, чтобы отправка/инжектирование специально сформированного сетевого пакета давала доступ к ME. А все остальные локальные способы вроде бы заблокированы Grsecurity.
AMT это на уровне чипсета. ОС о них знает мелочь, контроля она не имеет.
Безусловно. Тем не менее, чтобы обычное приложение из юзер-спейса как-то достучалось до AMT, эксплуатировало уязвимость и в результате этого ускользнуло из под контроля OS, ему нужно сначала сделать что-то (напр. писать в I/O порты). В этот момент приложение ещё находится под контролем OS, и ему, теоретически, можно помешать — смотря каким образом реализовано взаимодействие с AMT (о чём я и спрашивал, собственно).
В случае удалённой эксплуатации помешать невозможно, потому что пришедший по сети пакет будет сначала обработан AMT, до того как его сможет увидеть OS. А вот в случае локальной эксплуатации, судя по всему, доступ к AMT реализуется через I/O порты, доступ к которым для приложений в юзер-спейсе полностью контролируется OS, так что тот же Grsecurity вполне в состоянии защитить систему.
Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).
Учитывая говнокачество Intel RMM и ME я не удивлен этой дырой, вопрос был как быстро ее найдут. Все IPMI уязвимы ибо пишут их бангладешские говнокодеры, качество когда просто ужасно, если их смотреть. Хуже чем домашние рутеры. Тот же Supermicro посмотрите — это пи**ец.
Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).
А можно поподробней или ссылку на документацию? Просто я склоняюсь к мнению powerman, что удаленная эксплуатация подразумевает настроенный и открытый доступ по сети, не важно локальной или глобальной, а локально — использование интерфейса в ОС.
http://h10032.www1.hp.com/ctg/Manual/c03975296 или http://h10032.www1.hp.com/ctg/Manual/c02958196.pdf
From the Intel AMT Configuration menu (shown in Figure 5), select Manageability Feature Selection.
This option allows Intel AMT to be enabled (recommended) or disabled. By default, HP systems are set to enable Intel
AMT.
Note that disabling Manageability Feature Selection also disables all remote management capabilities and unprovisions
any Intel AMT settings.
То есть по умолчанию AMT активирован, что дает возможность удаленной эксплуатации. Но если его отключить, то исходя из описания уязвимости — все равно возможна локальная эксплуатация.
Прочтите сам PoC:
https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
Грубо говоря коннект к HTTP самого AMT.
AMT включен по умолчанию везде в системах с ним.
Локально взлом возможен через DHCP коннект к компьютеру: то есть локально поднять дхцп демона и по выданному ип зайти без пароля в AMT.
В принципе методов взлома тонна т.к. доступен HTTP
Почитайте бюллетень, в котором указано, что
An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology (SBT).
Исходя из терминологи, «provisioned system» — система с включенным AMT, «unprovisioned system» — с выключенным.
Если он выключен — то как он подхватит адрес по DHCP?
И по вашей же логике — я должен его всегда видеть в DHCP-клиентах на роутере. Но я этого не вижу.
Или для него нужны какие-то специфическиt опции в DHCP?
Все что вы описываете — это удаленная атака, так как она проводиться через сеть. Чем отличается локальный DHCP от DHCP в сети?
Ок, АМТ не может быть "выключенным" в принципе, насколько я понял.
Он всегда включен, однако порт можно отключить, если ПОЛНОСТЬЮ сбросить все в ноль.
A full unprovisioning returns Intel AMT to its factory default state.
Unprovisioned система значит настройки АМТ не введены и пароль дефолтный для системы.
Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.
Старые и новые AMT имеют разницу, поэтому от этого зависит.
Note that disabling Manageability Feature Selection also disables all remote management capabilities and unprovisions
any Intel AMT settings.
То есть, вроде как можно отключить и unprovision эквивалентно disable.
https://software.intel.com/en-us/forums/intel-business-client-software-development/topic/297931
(in fact, most systems will not even show the MEBx prompt if Intel AMT is disabled at the BIOS
Я не смог попасть в MEBx. Хотя биос был сброшен по дефолту и ATM настройки я не трогал. Я не вижу левых девайсов на DHCP.
Но вижу два девайса HECI:
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
Subsystem: Hewlett-Packard Company Device 198f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 50
Region 0: Memory at d0739000 (64-bit, non-prefetchable) [size=32]
Capabilities: <access denied>
Kernel driver in use: mei_me
Kernel modules: mei_me
00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04) (prog-if 02 [16550])
Subsystem: Hewlett-Packard Company Device 198f
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin D routed to IRQ 19
Region 0: I/O ports at 30b0 [size=8]
Region 1: Memory at d073f000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: serial
Насколько я понимаю, при возможности доступа к HECI девайсам, возможно получить доступ к AMT и ME, скорее всего используя ту же уязвимость (пустой пароль)
Собственно
Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.
Как я и написал.
Некоторые вендоры сбрасывают в DHCP, некоторые только в доступность через CTRL+P Некоторые вообще отключают. Зависит от вендора и версии AMT.
Potential Security Impact:
Remote escalation of privilege on provisioned systems or local escalation of privilege on unprovisioned systems.
Тон там немного истеричный (хоть и не без причины), но в целом очень интересно было почитать, спасибо. Насчёт "любая система выпущенная за последние 10 лет" — у меня (десктопная) материнка 5-ти летней давности на Intel® Z68 Express Chipset, и судя по спеке интела там ME нет вообще.
В следующей статье разбирается как раз этот вопрос — если в спеке интела сказано что ME/AMT нет, то нет ли его на самом деле, или физически в железе он всё-таки есть, просто не активен. Я, конечно, не стал бы исключать такой вариант, но по-моему эта проблема несколько раздута. Возможность удалённо эксплуатировать громадное количество систем отправив им сетевой пакет, вне зависимости от OS этих систем и даже того, включены ли они — это одно. Теоретическая (на данный момент) возможность взломать текущую OS конкретной системы с целью прошить заточенную под материнку конкретно этой системы нестандартную прошивку, которая активирует "как бы отсутствующий" в железе AMT, с целью его эксплуатировать — это уже перебор, господа! Я уже молчу о том, что такой подход будет "применим" всегда и к любой системе — кто помешает после обновления/удаления ME использовать этот подход чтобы сначала вернуть старую уязвимую прошивку а потом захватить AMT?
В общем, проблема была бы понятнее и нагляднее, если бы вокруг неё было меньше восторженной истерии.
ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше.
Даже SemiAccurate не утверждает этого наверняка. Вы более информированы на этот счёт? Есть пруфы или данное утверждение базируется на глубокой внутренней уверенности?
Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен.
Не совсем понял, как может быть "активен" ME, если судя по официальной спеке Intel ME отсутствует на этом чипсете и даже по Вашим словам AMT выключена. Как можно проверить, что ME есть и даже активен?
Я не знаю, что на материнки с этим чипсетом ставится под винду, у меня линух и таких драйверов нет. Но даже если он ставится — не факт, что он реально работает, а не отвечает "no such device" на любые запросы.
Действительно, в ядре есть драйвер "Intel Management Engine Interface" и созданное им устройство /dev/mei0.
Устройств с указанными ID я не вижу, но есть вот это:
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset Family MEI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 25
Region 0: Memory at f6607000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 41c1
Kernel driver in use: mei_meУпомянутая flothrone тулза MEInfo есть только под винду. Но я нашёл /usr/src/linux/Documentation/misc-devices/mei/mei-amt-version.c — теоретически она должна сказать активен ли AMT и показать его версию. Практически же она во-первых пытается работать с /dev/mei вместо /dev/mei0 (но это я поправил) и во-вторых выдаёт ошибку при попытке вызвать первый же ioctl после открытия /dev/mei0:
# ./mei-amt-version
Error: IOCTL_MEI_CONNECT_CLIENT receive message. err=-1В общем, странно всё это. Что-то вроде формально есть, но работать — не работает.
Чтобы убедиться в том, что ваш Intel ME живет и функционирует нормально, юзайте утилиту MEinfo.
если судя по официальной спеке Intel ME отсутствует на этом чипсете
И что за спецификацию на чипсет вы там читаете, если в даташите на этот чипсет есть описание регистров MEI (Management Engine Interface) в конфигурационном пространстве PCI?
Я там выше приводил ссылку на описание чипсета, и там сказано:
Intel® vPro™ Technology: No
Intel® ME Firmware Version: No
и вот уже в мае готов патч
А где его взять то? Вот у меня плата Intel DQ87PG — на странице загрузки из нового за последние полтора года только сообщение об окончании поддержки. Поиск по номеру прошивки выдаёт только длинные списки уязвимых продуктов и ссылки на PDF Intel рассказывающий как отключить AMT и службы в Windows.
В комментариях к твиту тоже нет пояснения. А вообще — да, пора уже бросать древный опасный неудобный С и писать всё на С++. Банальный std::string избавляет от необходимости держать в голове кучу фигни, и едва ли добавляет оверхед.
Ну вот и придется кому-то обновлять парк машин.
Во-вторых, там же написано — TrustZone, т.е. верить, они считают, можно. Нехорошо не доверять AMD, она не столько раз клиентов оставляла неудовлетворенными, чтобы в этот раз отвергнуть её. Шутка.
Ну а в третьих, несмотря на «волшебные» свойства ME, я бы поостерегся верить слухам: например, лично мне фраза «По слухам, даже шифрование диска ME обходит без напряга» кажется немного желтоватой. Хотя бы тем, что при шифровании данных на диске средствами ОС (драйвером работы с диском) прямой железный (т.е. мимо ОС) доступ к диску будет бесполезен, он даст только кучку защифрованных данных. Если же ME умеет ходить на диск через драйвера ОС, то не такая ME и неподконтрольная становится, в т.ч. и для проверки ее действий со стороны антивируса. А уж если данные на диске зашифрованы на уровне контроллера диска самим диском, то какая польза от ME?
В общем, доверяй, но проверяй. Тем более это читаем в блоге Касперского, которому кипишь на рынке безопасности, в общем-то, на руку (никаких обвинений, просто подумалось).
и снести из системы соответствующие утилиты IntelИнтересно, какие это утилиты?
Я недавно заинтересовался классифицировать все запускаемые на компьютере процессы и внезапно обнаружил, что у NVIDIA и Intel есть своя телеметрия (в частности, от Intel непонятно как в планировщик задач прописался «C:\Program Files (x86)\Intel\Telemetry 2.0\lrio.exe»)
Поэтому вполне вероятно, что и здесь просто установкой обновлений не отделаешься.
Security Week 18: Дыра во всех системах с Intel Core, Apple отобрала сертификат у троянца, рансомварь заполонила планету