LINUX.ORG.RU

Получен полный доступ к Intel ME

 , , ,


12

9

Хакеры Максим Горячий и Марк Ермолов сообщили о получении полного доступа к сервисному процессору Intel CSME через USB DCI. Ранее они уже демонстрировали возможность запуска неподписаного кода на сервисном процессоре.

В августе Максим Горячий публиковал код, который по всей видимости служит для перманентного отключения процессора (защита от воровства).

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от peregrine

Скорее всего Intel ME имеет доступ ко всем регистрам процессора в том числе.

Очень сомневаюсь. Иначе пришлось бы для каждой версии процессора готовить свою реализацию...

Serge10 ()
Ответ на: комментарий от Serge10

Очень просто, тебе было бы все более понятно, если бы ты был знаком с МТ. Если проще - все операции по чтению/записи так же подменены, при том не только при чтении с жесткого диска, но и чтении с оперативной памяти. Этого достаточно, чтобы шифрования как такового не было.

peregrine ★★★★★ ()
Ответ на: комментарий от Serge10

Вместо использования “оперативки”, алгоритм хранит секретные ключи в регистрах центрального процессора – восстановить их оттуда гораздо сложнее.

Да будет тебе известно, что при переключении потоков(у тебя явно не 100500 ядер) к примеру с браузера на ядро операционной системы значения регистров переносятся в оперативную память

NextGenenration ()
Ответ на: комментарий от Serge10

Не вижу, честно говоря, большой разницы.

То что ты не видишь ещё не говорит что её нет

Незаметно от Вас? И каким же образом? Я даже загрузиться после подмены ядра не смогу (нет ключа от зашифрованной корневой файловой системы).

Я заплатил за хостинг. Тут мне говорят: так и так, произошёл сбой и виртуалка упала. Для того чтобы её загрузить мне и потребуется ввести ключ. Я уже молчу о том что хостер контролирует канал через который я пароль передаю.

NextGenenration ()
Ответ на: комментарий от NextGenenration

Да будет тебе известно, что при переключении потоков(у тебя явно не 100500 ядер) к примеру с браузера на ядро операционной системы значения регистров переносятся в оперативную память

Надо с самим алгоритмом разбираться. Подозреваю, что такие ситуации там учтены.

Serge10 ()
Ответ на: комментарий от NextGenenration

Тут мне говорят: так и так, произошёл сбой и виртуалка упала. Для того чтобы её загрузить мне и потребуется ввести ключ.

Образ виртуалки должен был измениться, если там ядро меняли. Вы это вполне в состоянии заметить.

Serge10 ()
Ответ на: комментарий от peregrine

Если проще - все операции по чтению/записи так же подменены, при том не только при чтении с жесткого диска, но и чтении с оперативной памяти. Этого достаточно, чтобы шифрования как такового не было.

Правильно ли я Вас понимаю - получается, что на виртуальной машине в принципе невозможно поднять безопасный и защищенный канал?

Как-то вывод очень обескураживающе звучит :(...

Serge10 ()
Ответ на: комментарий от Serge10

Надо с самим алгоритмом разбираться

С каким алгоритмом? От того что я описал никуда не деться - в любой момент времени у любая программа может быть остановлена, а вместо неё запущена другая. Другая программа должна сохранить регистры первой, иначе первая поломается. Это происходит каждый день у кучи пользователей

NextGenenration ()
Ответ на: комментарий от Serge10

Правильно ли я Вас понимаю - получается, что на виртуальной машине в принципе невозможно поднять безопасный и защищенный канал?

Да. Чужую виртуалку ты не сможешь контролировать так же хорошо как и свой пк. Частично с этим должен был разобраться me, psp, trustzone, но если они разлочены, значит гарантий не дают ни каких. Если они залочены, то тоже не дадут гарантий, но по несколько другой причине

NextGenenration ()
Ответ на: комментарий от NextGenenration

И как ты это заметишь?

Ну, теоретически можно контрольные суммы считать для всех неизменяемых файлов (включая ядро). Примерно также, как работает защита от rootkit'ов.

Serge10 ()
Ответ на: комментарий от Serge10

Чем их проверять? Кстати, самый прикол в том, что чисто теоретически самый первый компилятор мог содержать бэкдор, который им встраивается во все новые компиляторы и не дает смотреть на него никакими средствами (т.е. компилятор встраивает код везде, где происходит чтение с диска), скрывая тем самым свое наличие. Единственный очевидный способ найти такое - точно знать размер накопителя и забить его бинариками под завязку. Если бинарики перестали копироваться, а размер диска предполагает что они должны копироваться, то такой бэкдор есть. На практике правда его реализация была бы крайне сложной и те кто делали первые компиляторы вряд ли о таком думали. Но чисто теоретически я не представляю адекватного способа поиска подобного кроме несоответствий каким-то параметром виртуальной системы системе реальной (не прибегая, конечно, к написанию машинного кода (который ещё надо безопасно ввести в компьютер), как авторы первых программ).

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от NextGenenration

Никогда не слышал о secure world, но слышал о ring privilege level, там ring 0 - незащищенный, ring 3 - защищенный (пользовательский). Вы об этом? Или есть какой то ring -3, о котором я не знаю? Не гуглится.

vlad9486 ()
Ответ на: комментарий от Serge10

Ну, теоретически можно контрольные суммы считать для всех неизменяемых файлов (включая ядро). Примерно также, как работает защита от rootkit'ов.

Никак. Для этого даже Intel ME не нужен, достаточно хакнутого гипервизора. Всё что в оперативной памяти - доступно хостеру. Всё что на диске - доступно хостеру. Модификация любых вычислений - доступна хостеру.

alt-x ★★★★★ ()
Ответ на: комментарий от Iron_Bug

людьми, которые выкачивали и дешифровали прошивку. это случилось ещё лет так десять назад.

Штеуд не стоит на месте и периодически переделывает это решение. Недавно на x86(или x64) перенесли. Да и потом, сейчас разве можно купить любой пк десятилетней давности в идеальном состоянии не за огроменную сумму?

NextGenenration ()
Ответ на: комментарий от Iron_Bug

10 лет назад возможно и были зачатки IntelME, я думаю, они вносят изменения этого зонда в каждую ревизию процессоров. Думаю, код 10-летней давности очень далек от нашей реальности.

sqq ()
Ответ на: комментарий от sqq

https://habrahabr.ru/company/pt/blog/336242/

Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC.

NextGenenration ()
Ответ на: комментарий от alt-x

Для этого даже Intel ME не нужен, достаточно хакнутого гипервизора.

Сломай человеку мир окончательно, рассказав про то, что даже приличный руткит будет всегда возвращать правильные контрольные суммы для тех файлов, которые он заменил. И вкатят его не всемогущие хостеры, а обычные скрипткидди, сквозь дырявый сервис в абсолютно надёжно зашифрованной виртуальной мойшыне.

Popil_Bablosov ()
Ответ на: комментарий от peregrine

Чем их проверять?

Что мешает скопировать на локальный компьютер и там посчитать?

Кстати, самый прикол в том, что чисто теоретически самый первый компилятор мог содержать бэкдор, который им встраивается во все новые компиляторы и не дает смотреть на него никакими средствами

Кошмар какой, Вас послушаешь, точно параноиком станешь :(.

Serge10 ()
Ответ на: комментарий от NextGenenration

Нельзя. Утилиту для подсчёта контрольных сумм тоже можно подменить.

См. выше. Что мне помешает скопировать то же ядро на локальный компьютер и там посчитать контрольную сумму?

Serge10 ()
Ответ на: комментарий от Popil_Bablosov

Сломай человеку мир окончательно,

Так уже :(.

что даже приличный руткит будет всегда возвращать правильные контрольные суммы для тех файлов, которые он заменил.

Это если на инфицированной машине считать. А если на независимой?

Serge10 ()
Ответ на: комментарий от Serge10

Это если на инфицированной машине считать. А если на независимой?

А «независимую» машину уже сделали зависимой через MT :)

Да, можно регулярно проверять содержимое виртуалки на чистой машине. Да, это поможет в определении есть/нет руткита. Но это совершенно не поможет в случае, когда злоумышленник контролирует железо/гипервизор. А после того, как сильная криптография стала повсеместно использоваться гражданами, вектора атак сместились именно в сторону контроля железа/гипервизора. Гражданам об этом сообщить забыли, конечно, поэтому вера в сильную криптографию как в «защиту от всего» только крепчает.

Popil_Bablosov ()
Ответ на: комментарий от Serge10

Что мне помешает скопировать то же ядро на локальный компьютер и там посчитать контрольную сумму?

Как минимум то что скачанное на локальном компьютере не выполняется на удалённом. Точно так же как можно пропатчить утилиты для контрольных сумм, точно так же можно пропатчить утилиты для скачивания. Кроме того к тебе вопрос - ты хоть раз занимался сверкой контрольных сумм у арендованного сервера? Рискну предположить что нет. Кроме того за этим надо следить день за днём. Можно просто оставить уязвимое ядро и запустить эксплоит. Вариантов масса. Прямо сразу же ты их не обнаружишь. Кроме того данный вариант абсолютно не годится для правоторговцев, которые постоянно боятся что у них что-то украдут. Им нужна веская гарантия, что drm ни в коем случае не расшифруют. То что в случае с видео это дело гарантированно расшифровывается перед выводом на матрицу экрана их не очень волнует

NextGenenration ()
Ответ на: комментарий от NextGenenration

Точно так же как можно пропатчить утилиты для контрольных сумм, точно так же можно пропатчить утилиты для скачивания.

Предполагается, что локальный компьютер Вы контролируете, в отличие от арендованного.

Кроме того к тебе вопрос - ты хоть раз занимался сверкой контрольных сумм у арендованного сервера?

Нет,не приходилось.

Кроме того за этим надо следить день за днём.

В принципе, это автоматизируется.

Им нужна веская гарантия, что drm ни в коем случае не расшифруют.

IMHO, задачу защиты контента бессмысленно пытаться решить техническими средствами...

Serge10 ()
Ответ на: комментарий от Popil_Bablosov

А «независимую» машину уже сделали зависимой через MT :)

Да ладно, почитайте исходное сообщение темы ;).

Но это совершенно не поможет в случае, когда злоумышленник контролирует железо/гипервизор.

Почему не поможет-то? Как раз в этих случаях и поможет. Просто регулярно проверяете контрольные суммы ключевых файлов на локальной машине, которую Вы контролируете целиком. В конце концов, Вы же бекап делаете виртуалки? Вот во время бекапа и проверяйте.

Serge10 ()
Ответ на: комментарий от Serge10

Предполагается, что локальный компьютер Вы контролируете, в отличие от арендованного.

Если тебе придут подменённые на этапе выгрузки файлы то контроль не поможет.

IMHO, задачу защиты контента бессмысленно пытаться решить техническими средствами...

Тем временем drm приняли в веб

NextGenenration ()
Ответ на: комментарий от Serge10

Почему не поможет-то?

Потому что если негодяй контролирует гипервизор, под которым запущена твоя VM, никаких изменений в гостевую систему вносить не нужно. Он просто сдампит память вместе со всеми ключами, после чего спокойно расшифрует данные.

Popil_Bablosov ()
Ответ на: комментарий от NextGenenration

у меня компов десятилетней давности штук пять дома стоит в углу. все в рабочем состоянии, в полном комплекте. иногда их использую, как ферму :) один старый пень работает сервером.

Iron_Bug ★★ ()