Уязвимость в KVM позволяет выполнять код вне гостевой системы на процессорах AMD.

Несколько дней назад исследователи из команды Google Project Zero опубликовали в своем блоге сообщение о том, что выявили уязвимость (CVE-2021-29657) в гипервизоре KVM (гипервизор на базе Linux с открытым исходным кодом, который поддерживает виртуализацию с аппаратным ускорением на x86, ARM, PowerPC и S / 390), позволяет избежать изоляции гостевой системы и запустите свой код на стороне хост-среды.

В сообщении упоминается, что проблема манифестирует от ядра Linux 5.10-rc1 до v5.12-rc6, то есть охватывает только ядра 5.10 и 5.11 (Большинство стабильных веток дистрибутивов не были затронуты этой проблемой.) Проблема заключается в механизме nested_svm_vmrun, реализованном с использованием расширения AMD SVM (Secure Virtual Machine) и позволяющем запускать гостевые системы вложенным образом.

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

Обсуждаемой ошибке был присвоен код CVE-2021-29657, он затрагивает версии ядра от v5.10-rc1 до v5.12-rc6 и был исправлен в конце марта 2021 года. Поскольку ошибка стала доступна для использования только в версии 5.10 и была обнаружена примерно через 5 месяцев, большинство реальных развертываний KVM не затронуты. Я по-прежнему считаю, что эта проблема представляет собой интересный пример работы, необходимой для создания стабильного перехода от гостя к хосту против KVM, и я надеюсь, что эта статья может доказать, что компрометация гипервизора - это не просто теоретическая проблема.

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

Проанализировав предложенную реализацию KVM, исследователиs обнаружила логическую ошибку, которая позволяет содержимому MSR (Регистрация в зависимости от модели) хоста быть под влиянием гостевой системы, который можно использовать для выполнения кода на уровне хоста.

В частности, запуск операции VMRUN из гостевой системы второго вложенного уровня (L2, запущенный из другого гостя) приводит ко второму вызову nested_svm_vmrun и повреждает структуру svm-> nested.hsave, на которую накладываются данные из vmcb из гостевой системы L2. .

В результате возникает ситуация, когда на гостевом уровне L2 можно освободить память в структуре svm-> nested.msrpm, которая хранит бит MSR, даже если он продолжает использоваться, и получить доступ к MSR хоста. окружающая среда.

Это означает, например, что гостевая память может быть проверена путем сброса выделенной памяти его процесса пользовательского пространства или что ограничения ресурсов для времени ЦП и памяти могут быть легко применены. 

Кроме того, KVM может переложить большую часть работы, связанной с эмуляцией устройства, на компонент пользовательского пространства.

Проблема присутствует в коде, используемом в системах с процессорами AMD (модуль kvm-amd.ko), и не проявляется в процессорах Intel.

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

Исследователи помимо описания проблемы они также подготовили рабочий прототип эксплойта который позволяет запускать корневую оболочку из гостевой среды в среде хоста в системе с процессором AMD Epyc 7351P и ядром Linux 5.10.

Замечено, что это первый гость, обнаруживший уязвимость в гипервизоре KVM сам по себе, не связанный с ошибками в компонентах пользовательского пространства, таких как QEMU. Исправление было принято в ядре в конце марта.

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


Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: Мигель Анхель Гатон
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.