Может ли виртуальная машина (ВМ) «взломать» другую ВМ, работающую на той же физической машине?

Вопросы:

1. Если ВМ повреждена (взломана), чем я рискую для других ВМ, работающих на той же физической машине?

2. Какие проблемы безопасности существуют между ВМ, работающими на одном и том же физическом узле?

3. Есть ли (можете ли вы составить) список этих (потенциальных) слабых мест и/или проблем?

Предупреждение:

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

Пожалуйста, предоставьте реальные факты, (серьезные) исследования, опытные проблемы или технические объяснения. Будьте конкретны. 

Примеры:

Два года назад я слышал, что могут быть проблемы безопасности, связанные с MMU (доступ к основной памяти других машин, я думаю), но я не знаю, является ли это практической угрозой на сегодняшний день или просто предметом теоретических исследований.

Я также обнаружил атаку «Flush+Reload», способную получить секретные ключи GnuPG на той же физической машине, используя кэш L3 процессора, даже если GnuPG работает на другой виртуальной машине.

Ответ 1

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

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

1. Атака на гипервизор. Если вы сможете получить достаточно привилегированную оболочку на гипервизоре данной ВМ, вы сможете получить контроль над любой ВМ в системе. Для этого нужно искать потоки данных, которые существуют из ВМ в гипервизор и сильно зависят от гипервизора; такие вещи, как паравиртуализированные драйверы, совместное использование буфера обмена, вывод на дисплей и сетевой трафик, обычно создают такие каналы. Например, вредоносный вызов паравиртуализированного сетевого устройства может привести к выполнению произвольного кода в контексте гипервизора, ответственного за передачу трафика драйверу физической сетевой карты.

2. Атака на аппаратное обеспечение хоста. Многие устройства позволяют обновлять прошивку, и если есть возможность получить доступ к механизму обновления из виртуальной машины, то вы можете загрузить новую прошивку, которая будет соответствовать вашим намерениям. Например, если вам разрешено обновить микропрограмму сетевой карты, вы можете заставить ее дублировать трафик, предназначенный для одного MAC-адреса (жертвы), но с другим MAC-адресом назначения (вашим). По этой причине многие гипервизоры фильтруют такие команды, где это возможно; ESXi фильтрует обновления микрокода процессора, когда они исходят от виртуальной машины.

3. Атака на архитектуру хоста. Приведенная вами атака, по сути, еще одна атака на раскрытие ключей на основе временных параметров, делает следующее: она использует влияние механизма кэширования на время выполнения операций, чтобы определить данные, используемые жертвой ВМ в своих операциях. В основе виртуализации лежит совместное использование компонентов; когда компонент используется совместно, существует возможность побочного канала. В той степени, в которой другая ВМ на том же хосте может влиять на поведение аппаратного обеспечения, работая в контексте ВМ жертвы, ВМ жертва контролируется злоумышленником. В упомянутой атаке используется способность ВМ контролировать поведение кэша процессора (по сути, общее универсальное состояние), чтобы время доступа жертвы к памяти более точно показывало данные, к которым она обращается; везде, где существует общее глобальное состояние, существует и возможность раскрытия информации. Если перейти к гипотетическим примерам, представьте себе атаку, которая манипулирует VMFS ESXi и заставляет части виртуальных томов ссылаться на одни и те же адреса физических дисков, или атаку, которая заставляет систему памяти считать, что часть памяти может быть общей, хотя на самом деле она должна быть частной (это очень похоже на то, как работают эксплойты use-after-free или double-allocation). Рассмотрим гипотетический MSR (model-specific register) процессора, который гипервизор игнорирует, но разрешает доступ к нему; он может быть использован для передачи данных между виртуальными машинами, нарушая изоляцию, которую должен обеспечивать гипервизор. Рассмотрим также возможность использования сжатия, чтобы дублирующие компоненты виртуальных дисков хранились только один раз – в некоторых конфигурациях может существовать (очень сложный) побочный канал, когда злоумышленник может узнать содержимое других виртуальных дисков, записывая данные на свой собственный и наблюдая за действиями гипервизора. Конечно, гипервизор должен защищать от этого, и гипотетические примеры были бы критическими ошибками безопасности, но иногда такие вещи используются.

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

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

При этом варианты, которые я упомянул выше (за исключением последнего в некоторых случаях), просто не существуют в пустых средах. 

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

Ответ 2

Возможны эксплуатации такого рода:

Редкие

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

Сложные и зависят от производителя

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

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

Ответ 3

Вот достаточно часто цитируемый Тео де Раадт из проекта OpenBSD:

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

В теории виртуализация должна обеспечивать полную изоляцию между виртуальными машинами и их хостом. На практике иногда встречаются уязвимости в безопасности, которые позволяют продвинутым злоумышленникам обойти эту защиту и получить доступ к другим виртуальным машинам или, что еще хуже, к их хосту (см. «Эмпирическое исследование подверженности безопасности хостов враждебных виртуальных сред»). Как упоминает Райан Рис, такие уязвимости довольно редки (что не означает, что их нет) и часто не раскрываются производителями, но они существуют. Если вы обеспокоены потенциальной возможностью таких атак (а я думаю, что в какой-то степени вы должны быть обеспокоены), я рекомендую вам не смешивать зоны безопасности на одном виртуальном хосте или кластере виртуальных хостов. Например, у вас будет выделенный кластер из двух виртуальных узлов для виртуальных машин DMZ, выделенный кластер для промежуточного ПО и выделенный кластер для защищенных активов. Тогда в случае использования уязвимости таким образом, что злоумышленник сможет подменить другие виртуальные машины или, что еще хуже, сам гипервизор, ваша модель безопасности останется неповрежденной.

Ответ 4

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