The OpenNET Project / Index page

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

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

26.05.2018 11:12

Группа исследователей из Общества имени Фраунгофера разработали технику атаки 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 3.0
Короткая ссылка: https://opennet.ru/48663-amd
Ключевые слова: amd, sev, virtual, attack, crypt, memory
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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 (low-end), или aix (high-end/cost). Сейчас появляется подход к решению подобных задач средствами (например) qemu-*. Пройдёт ещё N лет, и этим можно будет пользоваться (надеюсь). Я — за.
     

  • 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:
    Текст:



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

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