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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Придираться к конкурентам. Но, наверное, самое ясное, что он говорит во всей статье:

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

Когда-либо цитируемый Тео де Раддт проекта OpenBSD:

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

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

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