Критические уязвимости apparmor crackarmor: локальный root и выход из контейнеров

Критические уязвимости в AppArmor: локальный root, выход из контейнеров и обход политики безопасности

Исследователи компании Qualys обнаружили целый набор из девяти уязвимостей в системе мандатного контроля доступа AppArmor. Самые опасные из них позволяют обычному локальному пользователю без привилегий получить права суперпользователя (root), выйти за пределы контейнера и фактически обнулить смысл настроенных политик безопасности. Комплекс уязвимостей получил общее название CrackArmor, официальные CVE-идентификаторы ещё не присвоены.

Практическая эксплуатация этих ошибок уже продемонстрирована в современных дистрибутивах - в частности, в Ubuntu 24.04 и тестируемом Debian 13. Проблемы затрагивают LSM-модуль AppArmor в ядре Linux, начиная с версии 4.11 (2017 год), и актуальны для систем, где AppArmor активно используется: Ubuntu, Debian, openSUSE и SUSE. В линейке openSUSE/SUSE начиная с версии 16 по умолчанию задействован SELinux, однако AppArmor по-прежнему доступен как опциональный механизм и потому остаётся зоной риска.

Где именно "ломается" AppArmor

Ключом ко многим атакам стала фундаментальная логическая ошибка в AppArmor класса "обманутый посредник" (confused deputy). Она позволяет непривилегированному пользователю манипулировать профилями безопасности - загружать, заменять и удалять их по своему усмотрению. Для этого достаточно иметь возможность записи в специальные псевдофайлы в /sys/kernel/security/apparmor/:
- `.load` - загрузка нового профиля,
- `.replace` - замена существующего,
- `.remove` - удаление профиля.

Если атакующий может подменять профили, он фактически получает рычаг управления тем, какие ограничения действуют в системе. Это даёт несколько сценариев эксплуатации:

* полное выключение защиты для отдельных сервисов (например, снятие ограничений с cupsd или rsyslogd, что делает их уязвимыми к локальным и удалённым атакам);
* создание условий отказа в обслуживании (загрузка намеренно "запрещающих" профилей, которые блокируют работу ключевых процессов);
* обход ограничений пространств имён (namespaces) - например, загрузка особого профиля для "userns" или для /usr/bin/time, открывающего возможность создавать произвольное количество user namespace, игнорируя обычные лимиты.

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

Повышение привилегий через su/sudo и почтовую подсистему

Одна из наиболее интересных и показательных техник повышения привилегий опирается на подмену AppArmor-профилей для привилегированных утилит - таких как su и sudo. Идея в том, чтобы навязать им профиль, который искусственно ограничивает некоторые системные вызовы и способности (capabilities), но в выгодной для атакующего конфигурации.

Исследователи показали, как получить root-доступ через sudo за счёт:

1. Назначения для sudo нового AppArmor-профиля, который блокирует возможность менять идентификатор пользователя (операция setuid, связанная с CAP_SETUID).
2. Манипуляции переменной окружения `MAIL_CONFIG`, отвечающей за путь к конфигурации почтового сервера Postfix.

Механика такова: при возникновении ошибки или необычной ситуации sudo пытается уведомить администратора, отправив письмо через /usr/sbin/sendmail. В нормальной ситуации перед запуском sendmail процесс сбрасывает привилегии. Но если с помощью подменённого профиля запретить сброс привилегий, sendmail запускается уже с правами root. Далее, изменив `MAIL_CONFIG`, можно подсунуть почтовой подсистеме собственные настройки и заставить её использовать произвольный обработчик postdrop - бинарник или скрипт, который будет запущен с полными правами суперпользователя.

Таким образом, комбинация:
* подмена профиля AppArmor для sudo,
* запрет setuid,
* подмена почтовой конфигурации через переменные окружения
даёт надёжную цепочку эскалации привилегий.

Ошибки в коде ядра: use-after-free и двойной free()

Помимо логической "дыры" с профилями, в AppArmor обнаружены и классические ошибки на уровне ядра Linux: двойной вызов free() и обращение к уже освобождённой памяти (use-after-free). Они связаны с обработкой структур данных, отвечающих за загрузку и замену профилей безопасности.

AppArmor хранит загружаемый профиль в структуре `aa_loaddata`. Память под эту структуру выделяется из slab-кэша `kmalloc-192`. Из-за состояния гонки (race condition) возможна ситуация, когда структура уже освобождена, а код модуля по-прежнему обращается к прежнему адресу. Это даёт атакующему шанс перехватить управление над участком памяти, который сейчас считается "свободным", но ещё используется логикой AppArmor.

Исследователи показали, что такую уязвимость можно использовать для:

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

Фактически это даёт прямой путь к компрометации корневой учётной записи: после перезаписи строки в /etc/passwd злоумышленник может назначить заведомо известный пароль или вообще убрать необходимость пароля, получив полный доступ к системе.

Затронутые версии ядра и дистрибутивы

Уязвимости присутствуют во всех версиях ядра Linux, где AppArmor был включён в качестве LSM, начиная с ветки 4.11. Это означает, что под удар попадают:

* современные LTS-ветки Linux, если в них активирован AppArmor;
* дистрибутивы, которые традиционно используют AppArmor по умолчанию (Ubuntu, Debian, некоторые редакции openSUSE и SUSE);
* кастомные сборки ядра, где AppArmor включён вручную.

Даже если в конкретном дистрибутиве в качестве основной системы MAC выбран SELinux (как в новых версиях SUSE/openSUSE), наличие включимого модуля AppArmor в конфигурации ядра создаёт потенциальный вектор атаки, если администраторы используют или тестируют его параллельно с SELinux.

Патчи и статус обновлений

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

* 6.18.18
* 6.19.8
* 6.12.77
* 6.6.130
* 6.1.167
* 5.15.203
* 5.10.253

В Ubuntu заплатки для ядра уже включены в свежие обновления пакетов. Параллельно были выпущены обновления для sudo, sudo-ldap и пакета util-linux (включающего утилиту su): в них исправлены недостатки, которые позволяли более надёжно эксплуатировать уязвимости AppArmor и строить цепочки повышения привилегий.

В Debian подготовка обновления находится в процессе: исправления ядра и сопутствующих пакетов ожидаются в стандартном цикле обновлений, однако на стороне администраторов остаётся задача оперативно их установить.

---

Что это значит для администраторов и пользователей

Насколько опасен CrackArmor на практике

Набор уязвимостей CrackArmor особенно опасен тем, что:

1. Не требует удалённого доступа сам по себе. Достаточно любого способа получить локальный доступ к системе как обычный пользователь - дальше AppArmor перестаёт быть надёжной защитой.
2. Затрагивает популярные дистрибутивы. Ubuntu и Debian повсеместно используются на серверах и рабочих станциях; у многих из них AppArmor включён по умолчанию.
3. Позволяет обходить контейнерную изоляцию. Это удар по сценариям, когда безопасность строится на "слоёной" модели: контейнеры плюс MAC-политики. Если один из слоёв ломается, защита серьёзно ослабевает.

Особенно критичен риск для многопользовательских систем, серверов общего пользования, CI/CD-инфраструктуры, а также хостингов и VPS-провайдеров, где доверять локальным пользователям категорически нельзя.

Как проверить, подвержена ли система

Базовый чек-лист для администратора может выглядеть так:

1. Определить, используется ли AppArmor.
Проверьте, загружен ли LSM-модуль AppArmor и активны ли профили. Обычно это заметно по выводу утилит состояния или по наличию политик в системных каталогах конфигурации AppArmor.

2. Выяснить версию ядра.
Если ядро относится к веткам, где AppArmor уже был включён (4.11 и новее), а обновлений безопасности ещё не ставили, система с высокой вероятностью уязвима.

3. Оценить профиль использования sudo/su.
В системах, где sudo активно используется для администрирования, риск эскалации привилегий через цепочку sudo → sendmail → postdrop особенно высок.

4. Проверить контейнерную инфраструктуру.
Если контейнеры (LXC, Docker, podman и др.) завязаны на AppArmor-профили, следует считать их изоляцию ненадёжной до установки патчей.

Почему уязвимость в AppArmor столь показательная

CrackArmor подчёркивает несколько системных проблем в подходе к безопасности:

1. Сложность мак-механизмов. AppArmor, SELinux и аналогичные решения опираются и на политику, и на реализацию в ядре. Ошибка в одной из этих частей сводит на нет выгоду от другой.
2. Конфигурации "по умолчанию" часто переоценивают. Многие администраторы считают, что если дистрибутив поставляется с включённым AppArmor, то это автоматически делает систему значительно более защищённой. На практике неправильно сконфигурированные или уязвимые механизмы MAC создают ложное чувство безопасности.
3. Комбинируемость уязвимостей. Логические ошибки (confused-deputy с профилями) хорошо сочетаются с классическими багами на уровне памяти (use-after-free), что позволяет строить сложные, но очень мощные цепочки атак - вплоть до полной компрометации root.

Что стоит сделать разработчикам и командам безопасности

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

* пересмотреть модель угроз с учётом того, что локальный непривилегированный пользователь потенциально может обойти AppArmor;
* усилить процессы аудита кода в подсистемах безопасности ядра, особенно связанных с обработкой профилей и взаимодействием через sysfs;
* обновить внутренние руководства по эксплуатации и hardening: чётко прописать, что MAC - это не единственный уровень защиты, а часть более широкой архитектуры;
* внедрить систематическое тестирование на классы ошибок, подобные confused-deputy, а не только на переполнения буфера и классический memory corruption.

Что делать обычным пользователям Linux

Пользователям настольных систем и ноутбуков, использующих Ubuntu, Debian или производные, можно рекомендовать:

* как можно скорее установить доступные обновления системы, включая ядро и пакеты sudo / util-linux;
* избегать запуска подозрительного кода - особенно скриптов и бинарников, полученных из неофициальных источников;
* по возможности не предоставлять другим людям локальный доступ к своей машине с выделенными учётными записями.

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

---

CrackArmor наглядно демонстрирует, что даже зрелые и широко используемые системы мандатного контроля доступа не застрахованы от фундаментальных ошибок. Единственная реалистичная стратегия - своевременные обновления, многоуровневая архитектура безопасности и скептическое отношение к любым "магическим" защита́м, которые якобы раз и навсегда решают все проблемы.

Смотрят: 173