Йоанна Рутковска (Joanna Rutkowska), автор руткита Blue Pill, операционной системы Qubes OS и руководитель Invisible Things Lab, опубликовала (http://theinvisiblethings.blogspot.com/2011/05/following-whi...) документ (http://www.invisiblethingslab.com/resources/2011/Software...), в котором представила стразу три способа обхода защиты механизма виртуализации Intel VT-d (IOMMU), используемого в Xen и других гипервизорах для проброса реальных устройств на шине PCI в виртуальный домен. Все три метода основаны на возможности отсылки прерывания формата MSI с произвольным вектором прерывания из непривилегированного домена, имеющего доступ к адресному пространству устройства.
В первом случае используется генерация подложного SIPI-прерывания (Sturt-up Inter Processor Interrupt), которое в нормальной ситуации применяется в BIOS для активации всех ядер/процессоров системы. Легальные SIPI-прерывания могут быть инициированы только самим...URL: http://theinvisiblethings.blogspot.com/2011/05/following-whi...
Новость: http://www.opennet.me/opennews/art.shtml?num=30556
Яна что-то долго курила,CPU bugs, CPU backdoors and consequences on security
Loïc Duflot
Received: 10 September 2008
Accepted: 15 November 2008
Published online: 9 December 2008http://www.springerlink.com/content/d277442160362076/
Это не Яна курит - она как раз в 2008 и опубликовала. Просто в Ring0 дыр столько - что это вообще мелочи. Да и выше Ring 0 есть еще уровни.
Не, тетка клёвая, после Ковалевской, Кюри и Белки со Стрелкой. :)
Ей надо медаль дать только за то, что осилила Intel Software Development Manual.
И не просто прочитала, а вникла, поняла и нашла косяки.
>Ей надо медаль дать только за то, что осилила Intel Software Development Manual.И чего там такого сложного? Всё очень понятно и просто.
Зачёл статью и исходя из своих скудных знаний могу заключить, что ценность атаки практически нулевая, Яна исходит из того, что во время исполнения одного прерывания, в котором она (гипервизор) запрашивает много данных из медленной памяти устройства периферии (сетевухи к примеру), атакующий выполняет ещё одно прерывание (MSI), которое возвращается с ошибкой. Ключевым является момент, что процессор при исполнении второго прерывания хоть и запоминает регистры для первого, но при возвращении забывает восстановить один из них (%rax - собственно результат операции), а он в дальнейшем используется для вычислений. Причём надо заметить, что атака в основном направлена именно на реализацию в Xen.Итого: хоть теоретический анализ потрясает (меня во всяком случае), но я не представляю как такое можно применить на практике. Пока атакующий будет искать подходящие значения,чтобы переписать IDT (опять же как я понял это цель атаки, чтобы получить доступ в родительскую систему) он закрашит супервизор раз 100500, и надо не забывать, что ему ещё надо удачно попасть на медленную инструкцию копирования при прерывании.
Возможно интел решил, что закрывать такую "дыру" экономически нецелесообразно. Xen'овцы впрочем уже что-то у себя запатчили.
Падение гипервизора - уже DoS. Т.е. уже для хулиганов есть результат.
> Просто в Ring0 дыр столько - что это вообще мелочи.Дыры под Ring 0 ака дыры в "Ring -1" это не мелочи. Благодаря таким мелочам, может завестись дрянь которую вы не видите и даже самый злобный антивирь из режима ядра никогда не сможет это увидеть.
Таких специалистов бы с десяток и в лабораторию под патронажем спецлужб какой-нибудь страны и можно сказать, что оружие 21 века в области ИТ создано, контролируется и там где надо применяется.
Плохого мнения ты о спецслужбах... ;)
Только до неба спецслужбы тоже не превозносите. Прямо скажем уровень намного меньше чем те что ходят в мифах о этих самых спецслужбах.
> Только до неба спецслужбы тоже не превозносите. Прямо скажем уровень намного меньше
> чем те что ходят в мифах о этих самых спецслужбах.Ну как бэ доказательства и руткиты с иcпользованием VMX я видел ещё в 2006 году.
А ты думаешь, все так и побегут работать на спецслужбы?
> Таких специалистов бы с десяток и в лабораторию под патронажем спецлужб какой-нибудь
> страны и можно сказать, что оружие 21 века в области ИТ создано,Проблема только в том что во первых, спецслужбы не любят платить хорошую по мировым уровням зарплату уникальным специалистам. Поэтому там чаще всего работают сертифицированные раздолбаи, которых в более высокооплачиваемые места не взяли. Во вторых, у спецслужб напрочь вымораживающая бюрократия, не способствующая росту специалиста и его успешной работе над проблемой. Делают для галочки. В третьих, руткит вызовет ряд аномалий и рано или поздно будет обнаружен.
Изменение MSI через ping это клёво! :)
Зачем покупать процессоры Intel серии Sandy Bridge
чтоб был доступен Interrupt Remapping, если можно
вообще не покупать продукцию Intel?! :)Короча так и запишем - Сетевухи Intel e1000e унылое г...о,
Intel VT-d дырявый тормоз.
Как бы AMD-v поломали ещё раньше...
если почитать повнимательнее про работы этой же Рутковской
>Как бы AMD-v поломали ещё раньше...Пруфлинк или не было.
http://en.wikipedia.org/wiki/Blue_Pill_(malware)Blue Pill is the codename for a controversial rootkit based on x86 virtualization. Blue Pill originally required AMD-V (Pacifica) virtualization support, but was later ported to support Intel VT-x (Vanderpool) as well.
Я сам больше люблю AMD по ряду причин, но истина дороже.
а разве там не все равно какая система виртуализации используется - главное чтобы она была в железе? вначале сделали на АМД, потом на Интеле.
Истина дороже и она в том, что amd-v никто не ломал :)Blue Pill - это просто прототип руткита, способного скрывать своё присутствие в системе, используя технологию аппаратной поддержки виртуализции (любую, просто поддержку амд-в запилили раньше), а вовсе не малварь, способная выходить за пределы аппаратно-поддержанного гипервизора, как в топике. Т.е. утверждать, что этот руткит взломал AMD-V - всё равно, что утверждать, что любая малварь взломала x86, потому что использует его инструкции :)
Вы не путаете часом IOMMU с VMX? Интересно, а AMD 890FX IOMMU также уязвим, или...
> Зачем покупать процессоры Intel серии Sandy BridgeЧтобы интел мог ремотно выключать свой процессор СМСкой, разумеется.
AMD как всегда молодцы. У Интелов я вижу новость о сбоях вроде этого второй раз. Первый существовал с 80386 и только на нём.
Ну раз ты не слышал, то да, конечно, все хорошо.Вообще-то и в тех и в других за всю историю проскакивала куча багов и эксплоитов, о которых интернет-бездельники, разумеется, знать не знают.
Баг в x86_64 NOP, AMD K6-2 LOOP, баг в FPU пентиумов, баг 0xF00F в Pentium 2, баг в первых атлонах с MTRR, баг с делением в VIA C3... это очень навскидку.
Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит забывать :)А что такое "x86_64 NOP"?
> Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит
> забывать :)
> А что такое "x86_64 NOP"?Сейчас тебе скажут "как ты можешь не знать, ты что интернет-бездельник?!"
> А что такое "x86_64 NOP"?Видимо это когда 90h вместо традиционного недо-NOP неожиданно (для авторов компиляторов) стирало верхние 32 бит RAX, что привело к нескольким уязвимостям.
> Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит забывать :)Лочащий - не хакающий. К тому же выпустили воркэраунд на уровне BIOS.
> Лочащий - не хакающий.Особой разницы нет - навредить и этого хватит.
Я же не припоминаю Intel'ам их баги с пентиумами до 100 МГц, а только свежие найденные.
как раз в 90MHz-вом ошибка с делением была
> как раз в 90MHz-вом ошибка с делением быладаже формулу для вендового алькулятора вывели, чтоб экспресс-тест провести
> даже формулу для вендового алькулятора вывели, чтоб экспресс-тест провестиБыл также баг, когда некая последовательность байтов намертво вешала процессоры пентиум. Независимо от уровня привилегий. То-есть, бесправненький юзер в супернадежном qnx мог без проблем повесить всю систему, просто пхнув в проц "кривую" команду. Что вообще-то довольно существенная ошибка для процессора с разными уровнями привилегий.
См. пост выше, F00F - это оно и есть.
А если я эту функцию отключу в биосе, потому что она мне не нужна. то и багу отключу?
те тебе виртуализация не нужна?
Виртуализация возможна и без аппаратной. В статье на Википедии про AMD64 сказана интересная вещь о том, почему в 64-битной системе без аппаратной виртуализации виртуализация возможна на AMD, а на Intel невозможна. В 32-битной возможна у обоих.
VT-d != VT
Нужна, мне не нужен проброс PCI устройств внутрь гостя
Полагаю что без проброса PCI не нужна и функция VT-d, а значит нету и баги в таком случае. Или я все же не прав?
>Короча так и запишем - Сетевухи Intel e1000e унылое г...о,
>Intel VT-d дырявый тормоз.Эм.. а что с сетевухами e1000e не так?
Нет, действительно что там?
Реально ничего по этому поводу не слышал, поэтому и интересуюсь для своего/общего интереса/развития..
всегда работают нормально и без глюков. В отличие от иногда странно себя ведущих broadcom и marvell.
А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?
> А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?Господи, засирание еепрома уже эпичным багом называется. А cih тогда что? Совсем эпичный абзац, да?
Хм, вообще-то да.
>>Короча так и запишем - Сетевухи Intel e1000e унылое г...о,
>>Intel VT-d дырявый тормоз.
> Эм.. а что с сетевухами e1000e не так?
> Нет, действительно что там?
> Реально ничего по этому поводу не слышал, поэтому и интересуюсь для своего/общего
> интереса/развития..Generating MSI without access to device config space
However, we have discovered that even without access to the device configuration space 10, still in case of
many devices the driver would be able to program the device to generate an MSI, and consequently could
still mount a software-only attack against VT-d. This is because many devices support a so called Scatter
Gather mechanism, that allows to split one DMA transaction into several smaller ones, each destined to a
different memory location11.
The idea is to use such a scatter gather mechanism in order to generate a 4-byte memory write transaction
that will just happen to be destined to a special 0xfeeXXXXX address – in other words to generate MSI using
regular DMA write.
>А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?Ну все же.. это бага драйвера, а не самой сетевухи..
да уж... это драйвер надо было с костылём писать чтоли?