Comments
Клево, интересный обзор!

Вопрос: разве CVE-2014-2299 в Wireshark эксплуатируется удаленно? В тексте говорится про ситуацию, когда шарком на хосте анализируется трафик VM, а на видео эксплоит срабатывает при открытии пикапа, который на самом деле внутри не pcap, а mpeg, т.е. там нет пакетов, которые могли бы попасть в сетевой трафик.
Я так понял: «некий софт собирает пкап, и его шлет на ВМ для анализа, там то и вскрывается». Этот побег в ВМ правда))) Таким образом можно пывнить боксы антивирусников, например. Я однажды сделал RCE на VM для тестирования малварки доктора веба. Абсолютно бесполезное «проникновение» на операционный стол лаборатории.
После комментария ниже, понял суть атаки. Да, вектор направления другой, и это действительно ИЗ ВМ будет))
Да вы абсолютно правы CVE-2014-2299 это локальный по отношению к Wireshark баг. Я не совсем раскрыл саму суть атаки, сделаю это в комментарии: во многих sandbox-системах необязательно даже генерировать трафик для создания malformed pcap, можно напрямую компрометировать log директорию (где хранятся результаты деятельности текущего запущенного вредоноса) и перезаписать своим pcap с эксплойтом.
Я правильно понимаю, что почти все приведенные методы основываются на том, что есть некий гипотетический интерактивный пользователь, который залогинен и производит какую-то ненулевую активность? Т.е., грубо говоря, если говорить о том, что VM где-то удаленно, доступна только по какому-нибудь VNC / RDP / чему-то такому, то арсенал возможных действий сразу же снижается эдак на порядок?
Ну да, все как обычно, больше функциональность — больше простора для уязвимостей. Через VNC файл не кинешь.
Для VM в вакууме предлагается искать баги в самом софте виртуализации (два последних способа).
Ну с «шаред директориями» то же иногда вариант, как верно заметил, функциональность ключ к супеху, это золотые слова. Например, вполне реальная ситуация «побега»:

1) Имеем билд сервер с Дженкинс на ВМваре. Каким то магическим образом мы получили к нему доступ (через тот же Дженкинс, который криво оказался выставлен в Инет, а это RCE).
2) Пывнем эту ВмВару, и во время билда кладем в сорцы и, соответственно вРПМку бекдор => все это добро в корп. репо
3) Все обновляют пакет с репо => пывнем все корп боксы
4) Профит, побег с одной ВМваре на все боксы, без участия человека.

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

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

Так что VM escape – это не только хардкорная эксплуатация бинарных уязвимостей с обходом различных механизмов безопасности, но и хорошо забытое старое.
Слышал, у VMware есть некий интерфейс VMCI. Не знаю даже, для чего он нужен, честно говоря, но главный вопрос — возможно ли его использовать в целях «побега из ВМ»?
VMCI — это опциональный интерфейс для взаимодействия между виртуальными машинами.Он несомненно добавляет вектор атаки для vm-escape, потому всегда выключен по дефолту (например в ESXi).
Вот пример теоретического побега 2008 года, бага в VMCI
Only those users with full accounts are able to leave comments. Log in, please.