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

Вопросов:

• если виртуальная машина повреждена (взломана), чем я могу рисковать на других виртуальных машинах, работающих на той же физической машине?
• Какие проблемы безопасности возникают между виртуальными машинами, работающими на одном физическом хосте?
• Есть ли (вы можете сделать) список этих (потенциальных) недостатков и / или проблем?

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

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

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

• Примеры:

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

РЕДАКТИРОВАТЬ: Я также обнаружил, что эта атака "Flush + Reload" способна получить секретные ключи GnuPG на том же физическом компьютере, используя кэш L3 CPU, даже если GnuPG работает на другой виртуальноймашине. GnuPG был исправлен с тех пор.

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

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

• Атакуйте гипервизор . Если вы можете получить достаточно привилегированную оболочку на гипервизоре с данной виртуальной машиной, вы можете получить контроль над любой виртуальной машиной в системе. Способ решения этой проблемы - поиск потоков данных, которые существуют из виртуальной машины в гипервизор и сильно зависят от гипервизора; Такие вещи, как паравиртуализированные драйверы, совместное использование буфера обмена, вывод на дисплей и сетевой трафик, как правило, создают канал такого типа. Например, злонамеренный вызов паравиртуализированного сетевого устройства может привести к выполнению произвольного кода в контексте гипервизора, ответственного за передачу этого трафика физическому драйверу NIC.
• Атакуйте оборудование на хосте . Многие устройства позволяют обновлять микропрограмму, и, если это возможно, получить доступ к механизму для этого с виртуальной машины, вы можете загрузить новую микропрограмму, которая соответствует вашим намерениям. Например, если вам разрешено обновлять встроенное ПО на сетевой карте, вы можете заставить его дублировать трафик, привязанный к одному MAC-адресу (жертве), но с другим MAC-адресом назначения (вашим). По этой причине многие гипервизоры фильтруют такие команды, где это возможно; ESXi фильтрует обновления микрокода ЦП, когда они происходят от ВМ.
• Атакуйте архитектуру хоста, Атака, на которую вы ссылались, по сути, еще одна атака с раскрытием ключа на основе синхронизации, делает это: она использует влияние механизма кэширования на синхронизацию операций для определения данных, используемых виртуальной машиной-жертвой в своих операциях. В основе виртуализации лежит совместное использование компонентов; там, где компонент является общим, существует возможность побочного канала. В той степени, в которой другая виртуальная машина на том же хосте может влиять на поведение оборудования во время работы в контексте уязвимой виртуальной машины, она контролируется злоумышленником. Атака, на которую ссылаются, использует способность виртуальной машины управлять поведением кэша ЦП (по существу, общего универсального состояния), чтобы время доступа жертвы к памяти более точно отображало данные, к которым она обращается; где бы ни существовало общее глобальное состояние, Возможность раскрытия существует также. Чтобы перейти к гипотетическому приведению примеров, представьте себе атаку, которая массирует VMFS ESXi и заставляет части виртуальных томов ссылаться на одни и те же адреса физических дисков, или атаку, которая заставляет систему раздувания памяти полагать, что некоторая память может быть разделена, хотя на самом деле это должно быть private (это очень похоже на то, как работают эксплойты use-after-free или двойное распределение). Рассмотрим гипотетический MSR ЦП (регистр, зависящий от модели), который гипервизор игнорирует, но разрешает доступ; это может быть использовано для передачи данных между виртуальными машинами, нарушая изоляцию, которую должен обеспечивать гипервизор. Также рассмотрите возможность использования сжатия, чтобы дублирующие компоненты виртуальных дисков хранились только один раз - в некоторых конфигурациях может существовать (очень сложный) побочный канал, где злоумышленник может распознать содержимое других виртуальных дисков, записав его на собственное и наблюдая что делает гипервизор. Конечно, гипервизор должен защищать от этого, и гипотетическими примерами могут быть критические ошибки безопасности, но иногда эти вещи проскальзывают.
• Атакуйте другую ВМ напрямую . Если у вас есть проксимальный хост к виртуальной машине-жертве, вы можете воспользоваться преимуществами упрощенного контроля доступа или преднамеренного взаимодействия между виртуальными машинами в зависимости от того, как настроен хост и какие предположения делаются при развертывании управления доступом. Это только немного уместно, но оно имеет упоминание.

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

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

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

В теории нет. Весь смысл гипервизора состоит в том, чтобы изолировать виртуальные машины друг от друга.

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

Редактировать: я думал, что эта тема была сделана несколько месяцев назад, но она только что возродилась, и теперь OP просит больше «реальных фактов, цитируемых исследований» и т. Д., Так что я понял, какого черта.

Подвиги такого рода:

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

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

Вот довольно интересная статья об обратном, которая предполагает, что было проведено более нескольких атак на основе гипервизора.

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

Вот выдержка из полугодового отчета о тенденциях и рисках IBM X-Force 2010:

(Пожалуйста, откройте это изображение в новой вкладке, чтобы просмотреть его в полном размере.)

Обратите внимание на измеренный процент уязвимостей Escape to hypervisor, который звучит для меня довольно страшно. Естественно, вы захотите прочитать оставшуюся часть отчета, так как в нем гораздо больше данных для подтверждения заявлений.

Вот история о возможном эксплойте на гипервизоре Playstation 3, что забавно. Может быть, не так сильно влияет на ваш бизнес, если только ваш бизнес не Sony, и в этом случае он чрезвычайно эффективен.

Вот замечательная статья от Эрика Хоршмана из VMware, в которой он вроде как звучит как подростковый, полный анти-микро, но это все же хорошая статья. В этой статье вы найдете такие лакомые кусочки:

У жителей стеклянного дома Microsoft были другие камни, чтобы бросить наш путь. Microsoft указала на CVE-2009-1244 в качестве примера уязвимости прорыва гостя в ESX и ESXi. Взлом гостевого прорыва - серьезный бизнес, но, опять же, Microsoft искажает факты. VMware быстро отреагировала на исправление этой уязвимости в наших продуктах, и ESX был гораздо менее подвержен влиянию, чем Microsoft может заставить вас поверить:

Борьба среди конкурентов. Но, вероятно, самая ясная вещь, которую он говорит во всей статье, такова:

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

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

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

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

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