The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в механизме виртуализации Intel VT-d позволяет выйти за пределы изолированного окружения

14.05.2011 16:24

Йоанна Рутковска (Joanna Rutkowska), автор руткита Blue Pill, операционной системы Qubes OS и руководитель Invisible Things Lab, опубликовала документ, в котором представила сразу три способа обхода защиты механизма виртуализации Intel VT-d (IOMMU), используемого в Xen и других гипервизорах для проброса реальных устройств на шине PCI в виртуальный домен. Все три метода основаны на возможности отсылки прерывания формата MSI с произвольным вектором прерывания из непривилегированного домена, имеющего доступ к адресному пространству устройства.

В первом случае используется генерация подложного SIPI-прерывания (Start-up Inter Processor Interrupt), которое в нормальной ситуации применяется в BIOS для активации всех ядер/процессоров системы. Легальные SIPI-прерывания могут быть инициированы только самим процессором, но как выяснилось в ходе исследования, за них легко выдать обычное MSI-прерывание путем простого изменения значения поля "Delivery Mode". Получив SIPI-прерывание ядро начинает выполнение подготовительного (start-up) кода, адрес которого вычисляется с использованием номера вектора прерывания, что можно использовать для внедрения shell-кода. Однако, при переходе в режим виртуализации (VT-x), процессор блокирует (но запоминает) все INIT-прерывания, которые должны быть обработаны перед отсылкой SIPI-прерывания, поэтому shell-код может отработать только тогда, когда процессор выйдет из режима виртуализации, то есть на этапе выключения машины.

Второй метод - генерация MSI-прерывания с номером вектора 0x80 или 0x82, которые будут интерпретированы как системные вызовы или вызовы функций Xen, выполненные активным в данный момент доменом. Однако, единственный способ успешно выполнить атаку, это поймать момент, когда регистры процессора будут содержать нужные аргументы и номер системного вызова.

Третий метод заключается в генерировании прерывания с номером 17 (#AC), которое попадет к обработчику ошибок процессора. В результате значения стека будут интерпретированы неправильно и управление вернется к инструкции, расположенной по адресу RFLAGS:CS, а не CS:RIP, как того ожидает обработчик.

В конце документ содержит описание работы и фрагменты кода эксплойта, который использует второй метод и позволяет выйти за пределы непривилегированного Xen-домена. Получив предварительную версию документа разработчики Xen реализовали функциональность, которая запрещает обработку прерываний с номерами 0x80 и 0x82, если они были вызваны устройствами, а также блокирует доставку прерывания #AC. Однако первый метод до сих остается осуществимым, так что единственная серьезная защита против всех видов атак заключается в использовании механизма Interrupt Remapping (который блокирует незаконные прерывания от устройств), доступного пока только в процессорах серии Intel Sandy Bridge, выпущенных в начале текущего года.

Интересно, что Xen уже имел механизм ограничений на доступ к памяти устройств, проброшенных в виртуальные домены, который запрещал произвольное изменение вектора прерывания драйвером устройства. Но, как оказалось, его легко обойти с помощью механизма "Scatter Gather", поддерживаемого многими устройствами и позволяющего разбить одну DMA-транзакцию на несколько более мелких, с разными адресами назначения. Одним из таких адресов может быть область памяти, отведенная для записи MSI-прерываний.



  1. Главная ссылка к новости (http://theinvisiblethings.blog...)
  2. OpenNews: Уязвимость в процессорах Intel, позволяющая выполнить код на уровне SMM
  3. OpenNews: Qubes - новая безопасная операционная система на базе Linux и Xen
  4. OpenNews: Обнаружена локальная root-уязвимость, затрагивающая все Linux-ядра 2.6.x
  5. OpenNews: Началось бета-тестирование безопасного Linux-дистрибутива Qubes OS
  6. OpenNews: В безопасной ОС Qubes будет добавлена поддержка одноразовых изолированных окружений
Автор новости: Evgeny Zobnin
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30556-xen
Ключевые слова: xen, iommu, vt-d, virtual, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, AHAHAC (ok), 18:01, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Яна что-то долго курила,

    CPU bugs, CPU backdoors and consequences on security

    Loïc Duflot

    Received: 10 September 2008
    Accepted: 15 November 2008
    Published online: 9 December 2008

    http://www.springerlink.com/content/d277442160362076/

     
     
  • 2.7, letsmac (ok), 18:32, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не Яна курит - она как раз в 2008 и опубликовала. Просто в Ring0 дыр столько - что это вообще мелочи. Да и выше Ring 0  есть еще уровни.
     
     
  • 3.10, pavlinux (ok), 18:43, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Не, тетка клёвая, после Ковалевской, Кюри и Белки со Стрелкой. :)
    Ей надо медаль дать только за то, что осилила Intel Software Development Manual.
    И не просто прочитала, а вникла, поняла и нашла косяки.

     
     
  • 4.17, сальная сальвия (?), 22:23, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Ей надо медаль дать только за то, что осилила Intel Software Development Manual.

    И чего там такого сложного? Всё очень понятно и просто.

     
  • 4.27, Анонима (?), 05:28, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачёл статью и исходя из своих скудных знаний могу заключить, что ценность атаки практически нулевая, Яна исходит из того, что во время исполнения одного прерывания, в котором она (гипервизор) запрашивает много данных из медленной памяти устройства периферии (сетевухи к примеру), атакующий выполняет ещё одно прерывание (MSI), которое возвращается с ошибкой. Ключевым является момент, что процессор при исполнении второго прерывания хоть и запоминает регистры для первого, но при возвращении забывает восстановить один из них (%rax - собственно результат операции), а он в дальнейшем используется для вычислений. Причём надо заметить, что атака в основном направлена именно на реализацию в Xen.

    Итого: хоть теоретический анализ потрясает (меня во всяком случае), но я не представляю как такое можно применить на практике. Пока атакующий будет искать подходящие значения,чтобы переписать IDT (опять же как я понял это цель атаки, чтобы получить доступ в родительскую систему) он закрашит супервизор раз 100500, и надо не забывать, что ему ещё надо удачно попасть на медленную инструкцию копирования при прерывании.

    Возможно интел решил, что закрывать такую "дыру" экономически нецелесообразно. Xen'овцы впрочем уже что-то у себя запатчили.

     
     
  • 5.56, prapor (??), 10:57, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Падение гипервизора - уже DoS. Т.е. уже для хулиганов есть результат.
     
  • 3.43, Аноним (-), 20:25, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто в Ring0 дыр столько - что это вообще мелочи.

    Дыры под Ring 0 ака дыры в "Ring -1" это не мелочи. Благодаря таким мелочам, может завестись дрянь которую вы не видите и даже самый злобный антивирь из режима ядра никогда не сможет это увидеть.

     

  • 1.4, ФБР (?), 18:12, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Таких специалистов бы с десяток и в лабораторию под патронажем спецлужб какой-нибудь страны и можно сказать, что оружие 21 века в области ИТ создано, контролируется  и там где надо применяется.
     
     
  • 2.6, pavlinux (ok), 18:15, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Плохого мнения ты о спецслужбах... ;)
     
     
  • 3.39, alex (??), 17:11, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Только до неба спецслужбы тоже не превозносите. Прямо скажем уровень намного меньше чем те что ходят в мифах о этих самых спецслужбах.
     
     
  • 4.49, pavlinux (ok), 00:24, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Только до неба спецслужбы тоже не превозносите. Прямо скажем уровень намного меньше
    > чем те что ходят в мифах о этих самых спецслужбах.

    Ну как бэ доказательства и руткиты с иcпользованием VMX я видел ещё в 2006 году.

     
  • 2.35, Серж (??), 16:01, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А ты думаешь, все так и побегут работать на спецслужбы?
     
  • 2.44, Аноним (-), 20:29, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Таких специалистов бы с десяток и в лабораторию под патронажем спецлужб какой-нибудь
    > страны и можно сказать, что оружие 21 века в области ИТ создано,

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

     

  • 1.5, Лопато (?), 18:14, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Изменение MSI через ping это клёво! :)
     
  • 1.8, pavlinux (ok), 18:34, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Зачем покупать процессоры Intel серии Sandy Bridge
    чтоб был доступен Interrupt Remapping, если можно
    вообще не покупать продукцию Intel?! :)

    Короча так и запишем - Сетевухи Intel e1000e унылое  г...о,
    Intel VT-d дырявый тормоз.

     
     
  • 2.18, bircoph (ok), 23:07, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как бы AMD-v поломали ещё раньше...
    если почитать повнимательнее про работы этой же Рутковской
     
     
  • 3.23, Аноним (-), 00:54, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Как бы AMD-v поломали ещё раньше...

    Пруфлинк или не было.

     
     
  • 4.33, bircoph (ok), 13:13, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    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 по ряду причин, но истина дороже.

     
     
  • 5.34, ПолныйАнонимус (?), 13:19, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а разве там не все равно какая система виртуализации используется - главное чтобы она была в железе? вначале сделали на АМД, потом на Интеле.
     
  • 5.36, Анон (?), 16:12, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Истина дороже и она в том, что amd-v никто не ломал :)

    Blue Pill - это просто прототип руткита, способного скрывать своё присутствие в системе, используя технологию аппаратной поддержки виртуализции (любую, просто поддержку амд-в запилили раньше), а вовсе не малварь, способная выходить за пределы аппаратно-поддержанного гипервизора, как в топике. Т.е. утверждать, что этот руткит взломал AMD-V - всё равно, что утверждать, что любая малварь взломала x86, потому что использует его инструкции :)

     
  • 3.57, Alex (??), 21:33, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не путаете часом IOMMU с VMX? Интересно, а AMD 890FX IOMMU также уязвим, или...
     
  • 2.45, Аноним (-), 20:40, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Зачем покупать процессоры Intel серии Sandy Bridge

    Чтобы интел мог ремотно выключать свой процессор СМСкой, разумеется.

     

  • 1.12, Zenitur (ok), 19:17, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    AMD как всегда молодцы. У Интелов я вижу новость о сбоях вроде этого второй раз. Первый существовал с 80386 и только на нём.
     
     
  • 2.21, Аноним (-), 23:57, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну раз ты не слышал, то да, конечно, все хорошо.

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

    Баг в x86_64 NOP, AMD K6-2 LOOP, баг в FPU пентиумов, баг 0xF00F в Pentium 2, баг в первых атлонах с MTRR, баг с делением в VIA C3... это очень навскидку.

     
     
  • 3.24, Stax (ok), 02:31, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит забывать :)

    А что такое "x86_64 NOP"?

     
     
  • 4.30, Зенитар (?), 09:36, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит
    > забывать :)
    > А что такое "x86_64 NOP"?

    Сейчас тебе скажут "как ты можешь не знать, ты что интернет-бездельник?!"

     
  • 4.32, bockla (?), 11:44, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А что такое "x86_64 NOP"?

    Видимо это когда 90h вместо традиционного недо-NOP неожиданно (для авторов компиляторов) стирало верхние 32 бит RAX, что привело к нескольким уязвимостям.

     
  • 4.46, Аноним (-), 20:41, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Про баг в ранних Phenom с TLB, лочащий систему тоже не стоит забывать :)

    Лочащий - не хакающий. К тому же выпустили воркэраунд на уровне BIOS.

     
     
  • 5.54, Аноним (-), 09:31, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Лочащий - не хакающий.

    Особой разницы нет - навредить и этого хватит.

     
  • 3.29, Зенитар (?), 09:35, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я же не припоминаю Intel'ам их баги с пентиумами до 100 МГц, а только свежие найденные.
     
     
  • 4.40, Андрей (??), 18:43, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    как раз в 90MHz-вом ошибка с делением была
     
     
  • 5.41, Андрей (??), 18:44, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > как раз в 90MHz-вом ошибка с делением была

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

     
     
  • 6.47, Аноним (-), 20:46, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > даже формулу для вендового алькулятора вывели, чтоб экспресс-тест провести

    Был также баг, когда некая последовательность байтов намертво вешала процессоры пентиум. Независимо от уровня привилегий. То-есть, бесправненький юзер в супернадежном qnx мог без проблем повесить всю систему, просто пхнув в проц "кривую" команду. Что вообще-то довольно существенная ошибка для процессора с разными уровнями привилегий.

     
     
  • 7.51, Аноним (-), 02:28, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    См. пост выше, F00F - это оно и есть.
     

  • 1.13, Аноним (-), 19:32, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если я эту функцию отключу в биосе, потому что она мне не нужна. то и багу отключу?
     
     
  • 2.14, linux_must_die (ok), 19:40, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    те тебе виртуализация не нужна?
     
     
  • 3.16, Wormik (ok), 21:23, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Виртуализация возможна и без аппаратной. В статье на Википедии про AMD64 сказана интересная вещь о том, почему в 64-битной системе без аппаратной виртуализации виртуализация возможна на AMD, а на Intel невозможна. В 32-битной возможна у обоих.
     
  • 3.20, Michael Shigorin (ok), 23:48, 14/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    VT-d != VT
     

  • 1.15, Аноним (-), 19:48, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Нужна, мне не нужен проброс PCI устройств внутрь гостя
     
  • 1.19, Аноним (-), 23:17, 14/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Полагаю что без проброса PCI не нужна и функция VT-d, а значит нету и баги в таком случае. Или я все же не прав?
     
  • 1.25, c0rax (ok), 02:42, 15/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Короча так и запишем - Сетевухи Intel e1000e унылое  г...о,
    >Intel VT-d дырявый тормоз.

    Эм.. а что с сетевухами e1000e не так?
    Нет, действительно что там?
    Реально ничего по этому поводу не слышал, поэтому и интересуюсь для своего/общего интереса/развития..

     
     
  • 2.37, Stax (ok), 16:16, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    всегда работают нормально и без глюков. В отличие от иногда странно себя ведущих broadcom и marvell.
     
     
  • 3.38, sage (??), 16:29, 15/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?
     
     
  • 4.53, Аноним (-), 08:03, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?

    Господи, засирание еепрома уже эпичным багом называется. А cih тогда что? Совсем эпичный абзац, да?

     
     
  • 5.55, Аноним (-), 09:33, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хм, вообще-то да.
     
  • 2.50, pavlinux (ok), 00:35, 16/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Короча так и запишем - Сетевухи 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.

     

  • 1.42, c0rax (ok), 20:13, 15/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >А как же эпичный баг, когда линуксовый драйвер сжигал сетевухи e1000?

    Ну все же.. это бага драйвера, а не самой сетевухи..

     
     
  • 2.58, Карбофос (ok), 21:27, 18/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    да уж... это драйвер надо было с костылём писать чтоли?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру