dirtyfrag-arm64

arm64/aarch64 порт V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).

Протестировано на Ubuntu 24.04.4 LTS с linux-aws 6.17.0-1013-aws на AWS Graviton (самая новая доступная на момент написания).

Полный разбор с анализом обхода AppArmor, рекомендациями по усилению защиты и обнаружению: linnemanlabs.com/posts/porting-dirtyfrag-arm64

⚠️ Ограничения userns в AppArmor Ubuntu не предотвращают надежно эту эксплуатацию

Ubuntu имеет два sysctl AppArmor:

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

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

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Для получения дополнительной информации смотрите Two Hops and a Shell для полного анализа обхода AppArmor в Ubuntu.

Что отличается на arm64

Исходный PoC для x86_64 использует два пути эксплуатации: путь ESP/xfrm, который повреждает /usr/bin/su, и запасной путь rxrpc/rxkad, повреждающий /etc/passwd. На arm64 путь rxrpc вызывает kernel oops и не может быть использован. Путь ESP работает чисто.

Сбой rxrpc: flush_dcache_page

На x86_64 flush_dcache_page() является no-op. x86 имеет аппаратно-когерентные кэши данных/инструкций. На arm64 она выполняет реальное обслуживание dcache и разыменовывает метаданные struct page*. Когда путь шифрования rxrpc (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) вызывает flush_dcache_page на странице, ссылка на которую была изменена через цепочку splice/vmsplice, x86_64 молча пропускает это, но arm64 получает ошибку трансляции и вызывает oops:

pc : flush_dcache_page+0x18/0x58
lr : skcipher_walk_done+0xbc/0x260
     crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc]
     crypto_skcipher_encrypt+0x48/0xb8
     rxkad_secure_packet+0x108/0x270 [rxrpc]
     rxrpc_send_data+0x264/0x550 [rxrpc]

На протестированных мной системах arm64 запрет записи uid_map удалял рабочий путь ESP. Пространство имен может быть создано, но процесс не может отобразить себя в root внутри него или получить необходимые для настройки XFRM возможности в пространстве имен. Запасной путь rxrpc не предоставил рабочего пути повышения привилегий без пространства имен на arm64, вместо этого он вызывал oops ядра.

Работа только через ESP

На arm64 в моем тестировании был работоспособен только путь ESP. Этот путь требует создания пользовательского и сетевого пространства имен, а затем успешного отображения вызывающего пользователя в root внутри этого пространства имен. Усиление защиты дистрибутива может нарушить этот путь разными способами: Ubuntu может запретить запись uid_map через ограничения userns в AppArmor, я не тестировал на Debian/RHEL.

AppArmor: заблокирован по умолчанию, но обходится на Ubuntu

На протестированном мной образе Ubuntu 24.04 AWS apparmor_restrict_unprivileged_userns=1 блокировал прямую эксплуатацию из моей обычной SSH-сессии, запрещая запись uid_map внутри нового пространства имен.

Однако, при значении по умолчанию apparmor_restrict_unprivileged_unconfined=0, неограниченный пользователь может перейти в существующий профиль в режиме жалоб (например, runc) через aa-exec и обойти ограничение:

aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp

Установка kernel.apparmor_restrict_unprivileged_unconfined=1 блокирует этот путь и в настоящее время широко рекомендуется как решение для блокировки всех путей. Однако добавление еще одного aa-exec также обходит это:

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Смотрите ранее связанные посты для подробностей.

Специфичная для архитектуры нагрузка

Эксплойт перезаписывает /usr/bin/su в кэше страниц минимальным статическим ELF. Исходный PoC содержит x86_64 ELF с шеллкодом x86_64. Этот порт заменяет его эквивалентным aarch64 ELF:

• ELF e_machine: EM_AARCH64 (183) вместо EM_X86_64 (62)
• Шеллкод: инструкции aarch64 с использованием svc #0 вместо syscall
• Номера системных вызовов: setgid=144, setuid=146, setgroups=159, execve=221 (против 106, 105, 116, 59 на x86_64)
• Фиксированная ширина инструкций в 4 байта (против переменной длины x86_64), что приводит к немного большей нагрузке (~216 байт против 192)

Сборка и запуск

# Clone
git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git

# Build
cd dirtyfrag-arm64
gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil

# Run
./dirtyfrag_arm64 --force-esp

Флаг --force-esp полностью пропускает путь rxrpc, чтобы избежать ошибки ядра arm64.

Протестированное окружение

По состоянию на 2026-05-09 последнее доступное ядро Ubuntu 24.04 aws (6.17.0-1013-aws, собранное 24 апреля) поставляется без исправлений ни для Copy Fail (CVE-2026-31431, раскрыто 29 апреля), ни для Dirty Frag (CVE-2026-43284/43500, раскрыто 7 мая).

Немедленное смягчение

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

Занесите уязвимые модули в черный список

Безопасно на любой системе, не использующей активно транспортный режим IPsec или AFS. Чтобы предотвратить загрузку модулей, поместите следующее в /etc/modprobe.d/dirtyfrag.conf:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Обновите initramfs

Ubuntu также рекомендует перегенерировать initramfs, чтобы черный список присутствовал во время ранней загрузки:

update-initramfs -u -k all
``

### Удалите права на чтение у SUID-бинарников

Блокирует этот класс атак на основе splice на кэш страниц против этих SUID-целей. Эксплойту требуются права на чтение целевого файла для `splice()`. Пользователи по-прежнему могут выполнять бинарники.

**Не внедряйте это без тестирования в вашей среде и во всех ваших инструментах.**

```bash
chmod o-r /usr/bin/su

Это не исправление, а только смягчение. Существует еще много путей повышения привилегий.

Выгрузите модули

Чтобы выгрузить модули из работающей системы:

rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

Убедитесь, что они выгружены:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "Affected modules are loaded" \
  || echo "Affected modules are NOT loaded"

Сбросьте кэш страниц

Сброс кэша страниц должен удалить вредоносное содержимое и заставить файлы снова читаться с диска.

echo 3 > /proc/sys/vm/drop_caches

Примечание: у меня были некоторые непостоянные результаты с этим, но чем больше я пытаюсь воспроизвести, тем больше это работает как ожидалось. Для этого PoC вы можете проверить md5sum на /usr/bin/su, и если он не совпадает, перезагрузитесь.

Очистка после тестирования

Выполните шаг сброса кэша страниц, затем проверьте с помощью:

sha256sum /usr/bin/su

# Or from package manager:

dpkg -V util-linux    # Debian/Ubuntu
rpm -V util-linux     # RHEL/Amazon Linux

Превентивные меры

Для более проактивного подхода, который затрагивает весь класс уязвимостей (а не только конкретные CVE), смотрите полный разбор ограничений userns AppArmor, предотвращения предварительной загрузки модулей, обнаружения на основе Tetragon, а также правила YARA.

Благодарности

• Hyunwoo Kim (@v4bel) - оригинальное исследование уязвимости, раскрытие и PoC для x86_64
• SiCk - исследование обхода AppArmor в Ubuntu
• Keith Linneman / LinnemanLabs - порт для arm64, анализ сбоя flush_dcache_page, исследование AppArmor, заметки по обнаружению

Правовая информация

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

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

Лицензия

MIT. Копируйте, воруйте, изменяйте, учитесь на нем, делитесь своими улучшениями со мной. Или нет. Это код, делайте с ним что хотите.