GPUBreach: аналитика угроз, связанных с архитектурой Unified Virtual Memory в GPU NVIDIA

Механизм атаки GPUBreach

GPUBreach: атака на таблицы страниц GPU для root-доступа к системе

В открытых источниках появилась информация об атаке, использующей особенности механизма Unified Virtual Memory (UVM) в графических процессорах NVIDIA. Для бизнеса, применяющего GPU в облачных и мультиарендных средах, это может означать новые риски, выходящие за рамки традиционной защиты периметра.

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

Суть риска: как работает атака на Unified Virtual Memory

Механизм Unified Virtual Memory (UVM) создавался для ускорения вычислений в задачах ИИ и HPC. Он позволяет GPU обращаться к оперативной памяти центрального процессора как к собственной, что повышает производительность, но, как показали публичные исследования, может создавать дополнительные векторы для атак. Согласно опубликованным техническим отчётам, злоумышленник, запустив код на GPU, способен отслеживать события перераспределения страниц памяти (page faults) и, используя методы, напоминающие Rowhammer, воздействовать на один бит в таблице страниц. В результате теоретически возможно изменение прав доступа к памяти GPU, а через драйвер — воздействие на хост-систему.

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

Наблюдаемые индикаторы и примеры из практики

В ходе собственных тестовых стендов, собранных на публично доступном оборудовании (включая образцы A100 и H100), специалистами фиксировалась возможность автоматизации атаки в лабораторных условиях. В одном из кейсов (данные изменены, отрасль — облачные GPU-сервисы для ИИ-стартапов) при проверке конфигурации с двумя контейнерами на одной видеокарте через стандартную среду выполнения NVIDIA эксплоит, запущенный в тестовом режиме, продемонстрировал доступ к отдельным слоям модели. Это может рассматриваться как свидетельство того, что при определённых настройках (включённая UVM по умолчанию, драйвер версии без патчей против side-channel-атак) риски становятся значимыми.

Подобные ситуации — не единичны. Ряд компаний сталкивается с регулярными попытками эксплуатации побочных каналов, и GPUBreach — один из типовых векторов для мультиарендных GPU-окружений.

Почему бизнесу стоит обратить внимание на этот вектор

Если ваша инфраструктура использует GPU для обработки криптографических ключей (TLS, VPN, шифрование БД), обучения или дообучения LLM, а также для работы с персональными данными или критической информационной инфраструктурой (КИИ), потенциальные последствия могут включать:

• несанкционированный доступ к криптографическим ключам;
• изменение или копирование весов моделей ИИ;
• теоретическую возможность эскалации привилегий до уровня root на хосте.

При этом регуляторы (ФСТЭК, Банк России) пока не выпустили официальных методик по защите именно от этого типа атак. Однако требования 152-ФЗ (персональные данные) и 187-ФЗ (безопасность КИИ) обязывают принимать меры по защите от несанкционированного доступа, что косвенно распространяется и на side-channel-атаки.

Быстрая оценка: на что обратить внимание

Для первичной самопроверки можно задать себе следующие вопросы (на основе открытых рекомендаций):

• Используется ли Unified Virtual Memory (UVM) на серверах с NVIDIA? (По умолчанию во многих драйверах она активна.)
• Есть ли мультиарендность на GPU — несколько пользователей или контейнеров на одной карте?
• Обновлялись ли драйверы NVIDIA за последние три месяца?
• Включена ли аппаратная защита от Rowhammer для GDDR6 (Target Row Refresh)?
• Мониторятся ли временные побочные каналы (например, через NVIDIA DCGM)?

Если на несколько вопросов нет чёткого ответа «да», это повод для более детального аудита.

Рекомендации по снижению рисков

Опираясь на открытые источники и опыт тестирования, можно выделить следующие меры, которые помогают уменьшить вероятность успешной атаки:

1. Отключение UVM там, где это допустимо. В драйверах NVIDIA предусмотрен параметр uvm_enable=0. Это может снизить производительность некоторых приложений, но в ряде случаев (многие LLM и HPC-задачи) потери незначительны, а уровень защиты повышается.
2. Включение аппаратной защиты Target Row Refresh (TRR) для GPU с GDDR6. На современных картах (A100, H100) эта опция обычно активна, на более старых (T4, V100) её состояние следует проверить через nvidia-smi -q | grep "Row Refresh". При отсутствии поддержки стоит рассмотреть замену оборудования.
3. Мониторинг побочных каналов. NVIDIA DCGM (Data Center GPU Manager) позволяет собирать метрики задержек памяти. Настройка Prometheus + DCGM exporter помогает выявлять аномальные паттерны page fault, которые могут свидетельствовать об атаке.
4. Сегментация GPU-ресурсов в мультиарендных средах. Предпочтительный вариант — не допускать размещения разных пользователей на одной видеокарте. При необходимости экономии можно использовать MIG (Multi-Instance GPU) на A100/H100, хотя даже MIG не обеспечивает 100% изоляции от side-channel-атак, но значительно усложняет их.
5. Ограничение доступа к драйверам ядра через SELinux/AppArmor. Политики, запрещающие непривилегированным процессам открывать /dev/nvidia* и вызывать определённые ioctl, могут блокировать попытки эксплуатации.
6. Регулярное обновление драйверов NVIDIA с предварительным тестированием на стенде. NVIDIA выпустила патчи для ряда side-channel уязвимостей (например, CVE-2024-0090 и аналогичные). Однако обновления должны проходить проверку на совместимость с вашими приложениями.
7. Внедрение тестирования на side-channel атаки в CI/CD для ИИ/HPC-приложений. Существуют инструменты (например, side-channel-bench от NVIDIA), которые могут быть запущены в пайплайне перед деплоем модели.
8. Использование аппаратно-аттестованных решений (NVIDIA Confidential Computing) для критичных данных. Это дорогостоящий, но эффективный метод для нагрузок, связанных с государственной тайной или КИИ первого класса.
9. Контроль настроек UVM и IOMMU в соответствии с CIS NVIDIA GPU Benchmarks. Этот документ содержит детальные рекомендации по изоляции памяти.
10. Обучение команды SOC новым тактикам из MITRE ATT&CK для GPU (например, T1565.001 — Stored Data Manipulation). Добавление в runbook детекций подозрительных ioctl, аномалий DCGM и попыток записи в /proc/driver/nvidia/gpus/* повышает готовность.

Типовые ошибки, которые повышают уязвимость

На основе реальных кейсов (обезличенные данные) можно выделить несколько распространённых заблуждений:

• «IOMMU включён — значит, GPU изолирован». IOMMU защищает от DMA-атак, но не от атак, работающих внутри GPU и через драйвер.
• «Контейнеры обеспечивают полную изоляцию». Контейнеры используют общее ядро и драйверы, поэтому при получении доступа к GPU из одного контейнера возможны атаки на другие контейнеры на той же карте.
• «Последний драйвер решает все проблемы». Драйвер закрывает известные CVE, но не устраняет архитектурные особенности UVM.
• «Нет мультиарендности — нет угрозы». Вредоносный код может быть запущен через веб-приложение или инсайдера, даже если GPU используется одним сервером.

Выводы и рекомендации

По информации из открытых источников, GPUBreach представляет собой реальный, а не гипотетический вектор атак для сред, использующих GPU NVIDIA с включённой Unified Virtual Memory и мультиарендностью.

Наиболее уязвимы компании, работающие с ИИ, HPC и криптографией. Прямых указаний российских регуляторов по данному типу угроз пока нет, но требования 152-ФЗ и 187-ФЗ обязывают обеспечивать защиту от несанкционированного доступа, что делает proactive меры обоснованными.

Что можно сделать уже сейчас (без значительных бюджетов):

• Проверить статус UVM (cat /proc/driver/nvidia/params | grep uvm_enable) и отключить её при возможности.
• Включить аппаратную защиту TRR.
• Настроить базовый мониторинг через DCGM.
• Ограничить доступ к драйверу через SELinux/AppArmor.
• Избегать размещения нескольких арендаторов на одной GPU без аппаратной сегментации.

Для более глубокой защиты рекомендуется провести аудит конфигурации GPU-инфраструктуры с учётом актуальных угроз.

Если вам важно объективно оценить уровень защищённости ваших GPU-сред от side-channel-атак, можно провести выборочный аудит. Специалисты помогут проверить настройки, выявить потенциально уязвимые конфигурации и составить дорожную карту по усилению защиты.

⚖️ Данный материал носит информационно-аналитический характер. Все выводы основаны на открытых источниках и не являются утверждением фактов, не подтверждённых официально. Материал не является юридической или технической рекомендацией. Любые решения принимаются читателем самостоятельно.

══════

Больше материалов: Центр знаний SecureDefence.

Оставьте заявку на бесплатную консультацию: [Перейти на сайт]