The OpenNET Project / Index page

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

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

Йоанна Рутковска (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
Тип: Проблемы безопасности
Ключевые слова: xen, iommu, vt-d, virtual, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    Зачёл статью и исходя из своих скудных знаний могу заключить, что ценность атаки... весь текст скрыт [показать]
     
     
  • 5.56, prapor (??), 10:57, 16/05/2011 [^] [ответить]    [к модератору]  
  • +/
    Падение гипервизора - уже DoS. Т.е. уже для хулиганов есть результат.
     
  • 3.43, Аноним (-), 20:25, 15/05/2011 [^] [ответить]     [к модератору]  
  • +/
    Дыры под 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 +/
    Проблема только в том что во первых, спецслужбы не любят платить хорошую по миро... весь текст скрыт [показать]
     
  • 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... весь текст скрыт [показать]
     
     
  • 5.34, ПолныйАнонимус (?), 13:19, 15/05/2011 [^] [ответить]    [к модератору]  
  • +2 +/
    а разве там не все равно какая система виртуализации используется - главное чтобы она была в железе? вначале сделали на АМД, потом на Интеле.
     
  • 5.36, Анон (?), 16:12, 15/05/2011 [^] [ответить]     [к модератору]  
  • +2 +/
    Истина дороже и она в том, что amd-v никто не ломал Blue Pill - это просто пр... весь текст скрыт [показать]
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Ну раз ты не слышал, то да, конечно, все хорошо Вообще-то и в тех и в других за... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Был также баг, когда некая последовательность байтов намертво вешала процессоры ... весь текст скрыт [показать]
     
     
  • 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 сказана... весь текст скрыт [показать]
     
  • 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 не так?
    > Нет, действительно что там?
    > Реально ничего по этому поводу не слышал, поэтому и интересуюсь для своего/общего
    > интереса/развития..

    [b]Generating MSI without access to device config space[/b]

    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:
    Заголовок:
    Текст:


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