The OpenNET Project / Index page

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

26.05.2018 11:12  Найден метод обхода механизма защиты AMD Secure Encrypted Virtualization

Группа исследователей из Общества имени Фраунгофера разработали технику атаки SEVered, позволяющую обойти механизм защиты AMD Secure Encrypted Virtualization (AMD SEV) и получить полный доступ к зашифрованному содержимому памяти виртуальной машины, защищённой при помощи SEV.

Напомним, что технология SEV присутствует в последних поколениях процессоров AMD для серверных систем (AMD Epyc и Ryzen Pro) и позволяет защитить виртуальные машины от компрометации со стороны гипервизора или администратора хост системы. Суть метода защиты в интеграции в архитектуру виртуализации AMD-V возможности для прозрачного шифрования памяти виртуальных машин, при которой доступ к расшифрованным данным имеет только текущая гостевая система, а остальные виртуальные машины и гипервизор при попытке обращения к этой памяти получают зашифрованные данные.

Предложенный исследователями метод атаки позволяет в случае компрометации системы виртуализации и получения контроля за гипервизором извлечь в открытом виде все данные, находящиеся в памяти виртуальных машин, защищённых при помощи AMD SEV. Для совершения атаки не требуется физический доступ к оборудованию или возможность влияния на процессы в атакуемой виртуальной машине. Достаточно наличия виртуальной машины с любым сетевым сервисом (например, HTTP, SSH, FTP или почтовый сервер), отдающим через сетевые соединения данные, присутствующие в зашифрованной памяти виртуальной машины.

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

На первой стадии выполняется идентификация ресурсов - определяются страницы физической памяти (GPA, Guest Physical Address), в которых находятся отдаваемые через сетевой сервис данные. Процесс трансляции адресов в виртуальных машинах напрямую скрыт от гипервизора из-за использования SEV-шифования, но имеются методы определения страниц памяти на основе субъективного сопоставления активности в памяти и сетевом сервисе, которые можно комбинировать для повышения точности определения принадлежности ресурса.

На второй стадии выполняется непосредственно извлечение данных из памяти виртуальных машин. На стороне гипервизора в HPT (Host Page Table) выполняется изменение маппинга GPA (Guest Physical Address) в HPA (Host Physical Address), при котором вместо адреса отдаваемого через сетевой сервис ресурса указываются другие страницы памяти. После изменения отражения страницы памяти сетевой сервис выдаёт вместо ожидаемого контента (например, буфера с HTML-страницей) содержимое другой области физической памяти (в том числе памяти другой гостевой системы). Повторяя операцию и постепенно проходя по всем страницам памяти можно получить содержимое всей зашифрованной памяти гостевых систем.

Атака стала возможной из-за недоработки в архитектуре SEV, в которой трансляция виртуального адреса гостевой системы (GVA, Guest Virtual Address) в физический адрес гостевой системы (GPA, Guest Physical Address) контролируется исключительно самой виртуальной машиной, скрыто от гипервизора, но гипервизор по-прежнему отвечает за трансляцию SLAT (Second Level Address Translation), т.е может производить маппинг физических адресов гостевой системы (GPA) в физические адреса хост-системы (HPA, Host Physical Address). Подобная особенность даёт возможность гипервизору изменять раскладку памяти виртуальной машины.

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

  1. Главная ссылка к новости (https://www.theregister.co.uk/...)
  2. OpenNews: Компания AMD подтвердила наличие уязвимостей в своих чипах
  3. OpenNews: Заявлено о выявлении 13 серьёзных уязвимостей в процессорах AMD
  4. OpenNews: Уязвимость в процессорах AMD, позволяющая получить контроль над TPM-окружением
  5. OpenNews: Релиз ядра Linux 4.15
  6. OpenNews: Релиз ядра Linux 4.16
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: amd, sev, virtual, attack, crypt, memory
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 12:10, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]
  • –11 +/
    Это все преподносят так, как будто любой мамин кулхацкер может провертуть такую аферу. Истерия какая то, что с мелтдауном, что тут.
     
     
  • 2.2, cat666 (ok), 12:23, 26/05/2018 [^] [ответить]    [к модератору]
  • +24 +/
    Мамкин кулхацкер просто воспользуется готовым эксплоитом и все дела.
     
     
  • 3.41, Аноним (-), 10:04, 29/05/2018 [^] [ответить]     [к модератору]
  • –1 +/
    До этого этой штуки вообще небыло защиты виртуалки от гипервизора, и жили как-... весь текст скрыт [показать]
     
     
  • 4.45, Вы забыли заполнить поле Name (?), 16:03, 30/05/2018 [^] [ответить]    [к модератору]  
  • +/
    И действительно, кольца -1 не было никогда.
     
  • 4.46, PnDx (ok), 11:31, 31/05/2018 [^] [ответить]     [к модератору]  
  • +/
    До этого при необходимости доказывать невмешательство использовали или xen lo... весь текст скрыт [показать]
     
  • 1.3, Аноним (-), 12:26, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –4 +/
    Эпохальные события нынче. Будем надеяться на появление новых архитектур.
    Наверное, просто время пришло.
     
     
  • 2.4, Crazy Alex (ok), 12:29, 26/05/2018 [^] [ответить]    [к модератору]  
  • +5 +/
    К проблемам кокретных архитектур всё это ну никак не относится. А данный баг - вообще недоработка относительно нового механизма и не более
     
     
  • 3.6, Аноним (-), 12:54, 26/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Вообще-то тенденция тревожная - дыры нынче в железе, а не только в софте. С супер-навороченными архитектурами это, конечно, совсем никак не связано...
     
     
  • 4.15, Аноним (-), 14:00, 26/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Софт уже давно в железе, а не только в софте.
     
  • 4.17, demimurych (ok), 14:42, 26/05/2018 [^] [ответить]    [к модератору]  
  • +6 +/
    Дары в железе появились с момента когда его только ковать научились.
    Просто раньше, когда наделали к нему еще кучу дырявого софта этого было достаточно. Сейчас появились области где просто ошибок в ПО недостаточно и стали ковырять железки.
    Например в далекие уже 90тые годы был обнаружена дыра в процессоре 386 которая позволяла любой дос программе иметь доступ не к 1 мгб памяти а ко всем 4гб.
    И т.д. и т.п.
    Пообщайтесь с теми кто знает как работает мобильная связь. Там вообще симка это одна сплошная дыра
     
  • 4.18, Crazy Alex (ok), 14:47, 26/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Обычная тенденция. Более сложные задачи - более сложные системы их решают - больше дыр. Не лечится, если не хотите откатиться по возможностям и быстродействию.
     
  • 4.38, justBob (?), 19:25, 27/05/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    А "супер-навороченные архитектуры" это х86-гаунетцо, которое родом из 70-х?
     
  • 4.39, Аноним (39), 14:26, 28/05/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    F0 0F C7 C8
     
  • 2.27, Ю.Т. (?), 21:01, 26/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Лучше надейтесь на новые заворачивания гаек. Больше вероятность исполнения.
     
  • 1.5, Аноним (-), 12:40, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –5 +/
    Дыра на дыре дырой погоняет. Пусть эти дырявые артихитектуры отправляются в утиль. Нам нужна абсолютно новая архитектура с революционной парадигмой построения!
     
     
  • 2.7, kravich (ok), 12:54, 26/05/2018 [^] [ответить]    [к модератору]  
  • +8 +/
    Что, еще одна?!
     
  • 2.12, Нанобот (ok), 13:38, 26/05/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    > Нам нужна

    Кому это "нам"?


     
     
  • 3.37, Аноним (-), 18:00, 27/05/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Значит ботам не нужна.
     
  • 2.14, datorpele (?), 13:46, 26/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Теперь я понимаю, что взлом землянами компьютера космического корабля пришельцев в к/ф "День независимости" — не такая уж и фантастика.
     
  • 1.8, VINRARUS (ok), 12:56, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    И опять AMD FX осталься неуязвимым. :D
     
     
  • 2.11, AnonPlus (?), 13:37, 26/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    С тем же успехом можно сказать, что Ryzen, у которого в биосе отключено это шифрование, неуявзим.
     
  • 1.10, Аноним (-), 13:30, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Этож для полной виртуализации которая использует AMD-V
     
  • 1.20, Аноним (-), 15:54, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +3 +/
    Становится всё очевиднее, что производителям процессоров лучше не лезть в область безопасности дальше абсолютно необходимого минимума.
     
  • 1.28, Вареник (?), 21:15, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    >> Найден метод обхода механизма защиты AMD Secure Encrypted Virtualization

    Кто бы сомневался. Механизм защиты просто не внедрят без готового способа его обойти.

     
     
  • 2.29, Аноним (-), 21:51, 26/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    >Кто бы сомневался. Механизм защиты просто не внедрят без готового способа его обойти.

    Вареник срывает покровы с мировых заговоров!

     
  • 1.30, vitalif (ok), 22:04, 26/05/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Я что-то плохо понимаю, как вообще можно защитить виртуалку от хоста, если он вообще хост, а это вообще виртуалка. Банально, диск для виртуалки предоставляет кто? Не хост ли?)
     
     
  • 2.31, Аноним (-), 23:25, 26/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Это примерно как защита детей от их же родителей - так же эффективно и полезно
     
  • 2.32, Аноним (-), 08:19, 27/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Внезапно для дисков шифрование не проблема. Так что технология вполне нужная. Только вот у обоих производителей не работает, лол.
     
     
  • 3.33, Аноним (-), 09:48, 27/05/2018 [^] [ответить]    [к модератору]  
  • +/
    А пароль к диску откуда вводить будешь?
     
     
  • 4.34, anonymous (??), 10:37, 27/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Можно вводить хоть через SSH. Можно по SSH получать со своего хоста. Вариантов полно, было бы желание.
     
     
  • 5.40, angra (ok), 07:55, 29/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    И во всех этих вариантах надо сначала загрузить базовую систему с незашифрованного образа.
     
     
  • 6.42, Аноним (-), 10:09, 29/05/2018 [^] [ответить]     [к модератору]  
  • +/
    ну как-бы можно, вопос как с этим заморочиться Но у этой технологии в принцип... весь текст скрыт [показать]
     
  • 2.35, нурок (?), 11:28, 27/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    тем не менее появилась такая потребность, начали искать способы как это сделать, пока получилось только частично.
     
  • 2.43, sage (??), 12:26, 29/05/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Причем AMD с самого начала внедрения технологии так и говорила, что эта технология поможет в некоторых случаях защитить память виртуальных машин от прямого дампа, но не защитит от вредоносного гипервизора. Не понимаю, в чем здесь уязвимость как таковая. Это особенность технологии, о ней было заявлено с момента ее создания.
     
     
  • 3.44, КО (?), 09:38, 30/05/2018 [^] [ответить]    [к модератору]  
  • +/
    Не обязательно гипервизора. Любого драйвера который может подменять маппинг физической памяти для гипервизора.
     

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


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