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

Насколько я понял, для этого эксплойта нужен код режима ядра или IOPL. Но если взломщик достиг этого, то game уже over.

для вендузятников актуально

есть еще и руткит для венды на основе гипервизора, по сути венда работает в виртуальной машине , bluepill - redpill project, тоже заслуга этой же лаборатории

>для вендузятников актуально

не только

> Насколько я понял, для этого эксплойта нужен код режима ядра или IOPL. Но если взломщик достиг этого, то game уже over.

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

>Насколько я понял, для этого эксплойта нужен код режима ядра или IOPL. Но если взломщик достиг этого, то game уже over.

В случае успешного использования, уязвимость позволит: 1) Модифицировать поведение ядра, даже если оно собрано без поддержки загружаемых модулей 2) Если получены права root в одной из виртуальных машин, то можно будет получить контроль над реальной машиной целиеом.

>>Насколько я понял, для этого эксплойта нужен код режима ядра или IOPL. Но если взломщик достиг этого, то game уже over.

> В случае успешного использования, уязвимость позволит: 1) Модифицировать поведение ядра, даже если оно собрано без поддержки загружаемых модулей

Для использования этой уязвимости нужен рут, а он может модифицировать ядро и без модулей.

> 2) Если получены права root в одной из виртуальных машин, то можно будет получить контроль над реальной машиной целиеом.

Можешь процитировать место из статьи, где об этом говорится?

>> 2) Если получены права root в одной из виртуальных машин, то можно будет получить контроль над реальной машиной целиеом.

>Можешь процитировать место из статьи, где об этом говорится?

Это логично. Ведь обычно код виртуальной машины передается напрямую на исполнение процессору. Так что вполне можно предположить, что можно сделать jail-break.

>>> 2) Если получены права root в одной из виртуальных машин, то можно будет получить контроль над реальной машиной целиеом.

>>Можешь процитировать место из статьи, где об этом говорится?

>Это логично.

Весь взлом - результат ошибки. Я не ищу логику в ошибках.

> Ведь обычно код виртуальной машины передается напрямую на исполнение процессору.

И что?

>Можешь процитировать место из статьи, где об этом говорится?

лично я предлагаю это проверить, код есть по ссылкам там простой эксплойт под линукс, trusted computing тут не причём

sudo cat /proc/mtrr
\reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xd0000000 (3328MB), size= 128MB: write-back, count=1
reg04: base=0xd7f00000 (3455MB), size= 1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1

рут нужен, чтобы сделать uncachable во write-back, далее нужно заразить кэш, тогда этот код будет запущен с привилегиями SMM, чтобы вызвать SMI# я так понял нужно записать значение в какой-то из портов

>> Ведь обычно код виртуальной машины передается напрямую на исполнение процессору.

>И что?

А то, что ты "хакнешь" реальный процессор.

> рут нужен, чтобы сделать uncachable во write-back, далее нужно заразить кэш, тогда этот код будет запущен с привилегиями SMM, чтобы вызвать SMI# я так понял нужно записать значение в какой-то из портов

Для этого нужен рут. KVM можно пустить и без рута.

>Для этого нужен рут. KVM можно пустить и без рута.

тогда можно сильно не нервничать

>> Можешь процитировать место из статьи, где об этом говорится?

> Это логично. Ведь обычно код виртуальной машины передается напрямую на исполнение процессору. Так что вполне можно предположить, что можно сделать jail-break.

Логично, но я не знаю как работает "аппаратная" виртуализация в интелях, так что проверки требует.

> рут нужен, чтобы сделать uncachable во write-back, далее нужно заразить кэш, тогда этот код будет запущен с привилегиями SMM, чтобы вызвать SMI# я так понял нужно записать значение в какой-то из портов

Бедные специалисты по безопасности уже не знают как бы им еще пропиариться. :) Насколько я понял, чтобы воспрользоваться этой уязвимостью нужно сначала вылезти в режим ядра (после этого уже и так можно поставить систему в какую угодно позу). Однако, SMI# (как пишут в мануале, на практике уже много лет никто эту хрень не использует) -- это прерывание и его можно послать только через шину APIC. То есть на атакуемой системе надо незаметно запихнуть спец. плату в PCI разъем, чтобы она в нужный момент сгенерировала SMI#. Хороша уязвимость! :D

>То есть на атакуемой системе надо незаметно запихнуть спец. плату в PCI разъем, чтобы она в нужный момент сгенерировала SMI#.

5 SMI stands for System Management Interrupt. On Intel chipsets an SMI# can be triggered by executing OUT instruction to port 0xb2 .

это сноска из мануала, а так же мне кажется, что при управлении питанием процессора тоже используется этот режим

> это сноска из мануала

Ну, стало быть не заметил. А какой том?

> а так же мне кажется, что при управлении питанием процессора тоже используется этот режим

Сейчас для этих целей используется SpeedStep, а это фактически просто набор MSRов, которые читаются и пишутся прям из protected mode.

>Ну, стало быть не заметил. А какой том?

это из статьи этих друзей

http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf

видимо это чипсетозависимо