Уязвимость кучи VirtualBox продолжает жить.
Черновик от 2017 года раскрывает CVE-2017-3558 — дефект в стеке NAT-соединений VirtualBox, который позволяет гостевой виртуальной машине пробраться в пользовательское пространство хост-системы. Спустя восемь лет пути выполнения кода остаются пугающе похожими — настолько, что это заслуживает нового внимания в сегодняшнем мире, переполненном контейнерами.
Как куча Slirp в VirtualBox подрывает изоляцию
Slirp, этот эмулятор сетевого стека пользовательского режима старой школы, обеспечивает работу NAT как в QEMU, так и в VirtualBox. Он “всасывает” сырые IP-пакеты из эмулируемой сетевой карты гостя, переупаковывает их и отправляет через сокеты хоста — без необходимости привилегий ядра. Умное решение, не правда ли? Но VirtualBox сильно его модифицирует: порты удаляются, добавляются кастомные аллокаторы.
Каждый NAT-интерфейс получает свой собственный аллокатор зон — 3072 блока по 2048 байт каждый, nmbclusters=1024+32*64. Список свободных блоков (freelist) начинается с конца и движется к началу. Встроенные метаданные предваряют каждый блок:
struct item {
uint32_t magic; // (всегда 0xdead0001)
uma_zone_t zone; // (указатель на зону; uma_zone_t это struct uma_zone *)
uint32_t ref_count;
struct {
struct type *le_next; // (следующий элемент)
struct type **le_prev; // (адрес предыдущего le_next)
} list; // (элемент в freelist или в used_items, списке используемых блоков кучи)
};
Освобождение памяти каскадом: m_freem → m_free → mb_free_ext → uma_zfree → uma_zfree_arg → slirp_uma_free.
Вот где кроется проблема. Функция uma_zfree_arg() проверяет префикс:
void uma_zfree_arg(uma_zone_t zone, void *mem, void *flags) {
struct item *it;
[...]
it = &((struct item *)mem)[-1];
Assert((it->magic == ITEM_MAGIC));
Assert((zone->magic == ZONE_MAGIC && zone == it->zone));
zone->pfFree(mem, 0, 0); // (zone->pfFree это slirp_uma_free)
[...]
}
Assert() исчезает в релизных сборках — тех, что с официальной страницы загрузок VirtualBox. Никакой проверки magic, никакой валидации zone.
Затем slirp_uma_free() вслепую доверяет it->zone, получает pfFini и вызывает:
{управляемый указатель}({управляемый указатель}, {указатель на данные пакета}, {управляемый u32});
Произвольный вызов. Из кучи, управляемой гостем.
Смогут ли атакующие эксплуатировать это в 2025 году?
Стагнация кода — вот главная проблема. В заметке отмечается: “большая часть описанного кода, похоже, с тех пор мало изменилась”. Поверхностная проверка исходников VirtualBox 7.0 — скелет slirp_uma_free сохранился. Удаление Assert() в релизных сборках? Тоже на месте. На Linux-хостах, непереносимые бинарные файлы только усугубляют ситуацию; шаблоны memcpy() помогут с ROP, если потребуется.
Гость отправляет специально сформированные Ethernet-кадры — переполняет кучу, разбивает структуру item блока. Указывает it->zone на данные злоумышленника. pfFini направляется на записываемый гаджет. Пользовательское пространство хоста оказывается под контролем. Переход в ядро был незавершённой частью; можно думать о повышении привилегий через VBoxDrv.
Риск? Высокий для виртуальных машин на общем хостинге, для пентестов или лабораторий red-team. Привлекательность NAT — файрвол для гостей — оборачивается против пользователя.
Параллели с грехами аллокатора Heartbleed. Вендоры исправляют симптомы, игнорируя корень проблемы. PR VirtualBox? Молчат об этом возрождении; никаких бюллетеней, кроме 2017 года.
Побег в пользовательское пространство — это не RCE в ядре, но это уже серьёзный шаг. Оттуда до уязвимостей в ядре Linux рукой подать — вспомните Dirty COW, например.
Прогноз: государственные структуры могут использовать это для проведения операций в изолированных средах. Зачем возиться с нулевым днём в ядре, когда можно быстрее получить доступ к пользовательскому пространству?
Почему сетевое взаимодействие ВМ остаётся минным полем
Режим NAT маскирует трафик гостя под трафик хоста. Удобство вместо безопасности. Привлекательность Slirp в пользовательском режиме рушится под натиском переполнения кучи.
Альтернативы? Бриджинг-сеть выставляет гостей наружу — обязательны файрволы. Или использование eBPF хоста для политик. Но инерция правит бал; миллионы пользователей ежедневно запускают VBox NAT.
Кураторство Oracle вызывает критику. Бесплатно, богато функциями, но исправления запаздывают. Этот призрак 2017 года доказывает: гипервизоры ВМ — это не крепости.
Минимизируйте риски сейчас. Отключайте NAT, где это возможно. Используйте строгие сборки, если компилируете сами. Проверяйте гостей — вредоносное ПО обожает переполнение пакетов.
Неисправленный путь из ВМ в пользовательское пространство хоста. Пугающе прямолинейный.
🧬 Связанные материалы
- Читать подробнее: 78% фабрик Великобритании стали жертвами кибератак в прошлом году – советы директоров зевают
- Читать подробнее: Простой трюк ГРУ с роутерами позволил получить токены Microsoft из 18 000 сетей
Часто задаваемые вопросы
Что такое CVE-2017-3558 в VirtualBox? Побег из гостевой ВМ в пользовательское пространство хоста VirtualBox через повреждение кучи Slirp в режиме NAT, позволяющий выполнять произвольные вызовы в пользовательском пространстве.
Безопасен ли VirtualBox NAT в 2025 году? Не полностью — основные недостатки сохраняются; вместо этого используйте режимы bridged или host-only.
Как защититься от побегов из ВМ? Изолируйте гипервизоры, отключайте ненужные сетевые соединения, отслеживайте аномалии использования кучи.
