На этом всё. Никаких специальных CAP_*, никакого доступа к файловой системе хоста. Атакующий помещает самодостаточный статически слинкованный бинарник в контейнер, запускает его — и повреждение page-cache, а следовательно и хук, становится видимым для всех соседних контейнеров.

Как эксплойт собирается в цепочку

1. Идентичность страниц page-cache. В контейнере на overlayfs путь /usr/lib/.../libc.so.6 обслуживается ext4-inode нижнего слоя образа. Каждый контейнер, запущенный из того же образа, разделяет этот нижележащий inode, а page-cache ядра индексируется по нижележащему inode — не по overlay и не по пространству имён. Поэтому одна 4-байтовая запись в страницу page-cache видна всем процессам соседних контейнеров, у которых эта страница отображена через mmap.

2. Уязвимость AF_ALG aead превращает одну такую запись во множество. algif_aead сцепляет пользовательский RX iovec с хвостовыми authsize байтами сцепленного TX SGL, а при ротации ESN в authencesn 4 байта поля seq_high из AAD размещаются в dst[assoclen + cryptlen] — то есть в первом байте этого сцепленного чужого хвоста. Сцепленная страница — это страница page-cache файла, к которому атакующий имеет только доступ на чтение, но шифр всё равно копирует в неё байты, не помечая страницы как dirty. (Подробнее о механике — в crypto/algif_aead.c и crypto/authencesn.c.)

3. Инициализация вызываемого примитива. Первым делом page_inject разворачивает зону A — закодированную на asm повторную реализацию той же схемы AF_ALG (write_cache.asm), размещённую в кармане секции .text libc. Это превращает 4-байтовую запись в обычный call из любого будущего кода хука — без необходимости настраивать сокет для каждого вызова.

4. Установка хука. Затем инжектор записывает зону C (zone_c.asm) в карман секции .text libc и патчит первые 7–12 байт read() переходом E9 disp32 на неё. Вытесняемые байты пролога точно эмулируются в быстром пути зоны C (распознаются три разных пролога glibc — см. «Обработка пролога read()» ниже). Теперь хук активен в page-cache libc.

5. Распространение хука. В каждом соседнем контейнере процессы постоянно вызывают read() (демоны журналирования, healthcheck-скрипты, cat /etc/hostname — что угодно). При первом таком вызове внутри соседнего контейнера перехваченный пролог прыгает в зону C, которая:

   • выполняет stat("/") для корневого inode контейнера (стабильный идентификатор для каждого пространства имён) и использует его как ключ слота контейнера;
   • сканирует таблицу слотов в поисках существующей записи с этим ключом;
   • если записи нет, регистрирует ключ и fork()-ает долгоживущего дочернего процесса командного цикла, который опрашивает область CMD на предмет команд;
   • возвращается к read()+N, так что вызывающий код ничего не замечает. Исходный процесс соседнего контейнера продолжает работать. С этого момента у атакующего есть демон внутри этого контейнера.

6. Канал команд. Атакующий использует тот же бинарник page_inject в режиме --shell, чтобы записывать команды в область CMD региона слотов. Дочерний процесс хука каждого зарегистрированного соседнего контейнера опрашивает её, запускает /bin/sh -c <cmd>, захватывает stdout/stderr в область OUTPUT, сигнализирует о завершении и возвращается к опросу. Shell показывает вывод. Поскольку каждая запись в CMD/OUTPUT тоже идёт через примитив уязвимости, никаких особых привилегий не требуется.

7. Снятие хука. По завершении работы unhook восстанавливает исходные байты пролога read() и обнуляет таблицу слотов; дочерние процессы хуков при следующей итерации видят пустой слот и завершаются сами. Сами изменения page-cache чистые (ядро никогда не помечало изменённые страницы как dirty), поэтому как только все контейнеры с отображённой через mmap libc остановлены, drop_caches полностью восстанавливает кэш — на диске не остаётся никаких следов.

Сборка

Инжектор собирается вне контейнера-жертвы — как правило, на собственной машине разработки атакующего, — потому что в большинстве продакшен-образов контейнеров нет компилятора. Достаточно стандартного окружения разработки Linux x86_64 с gcc (с поддержкой статической линковки -static) и nasm.

Результат сборки — единый статически слинкованный ELF (./page_inject), который запускается на любом современном ядре Linux x86_64.

Доставка и использование (из контейнера-жертвы)

Получив shell в victim, атакующий загружает бинарник в доступный для записи каталог (обычно /tmp):

Без аргументов page_inject использует путь по умолчанию /usr/lib/x86_64-linux-gnu/libc.so.6 (расположение Debian/Ubuntu после объединения каталогов). В других дистрибутивах libc лежит по другому пути; можно либо передать его явно, либо использовать --root /, чтобы просканировать встроенную таблицу путей от корня контейнера:

Оба варианта запуска делают одно и то же: разбирают ELF внутриконтейнерной libc, устанавливают хук в её page-cache, ~30 секунд наблюдают за таблицей слотов, пока регистрируются соседние контейнеры, и в качестве проверки работоспособности однократно выполняют id в первом зарегистрировавшемся соседнем контейнере.

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

unhook одним действием убирает хук из всех соседних контейнеров и позволяет дочерним процессам хука завершиться самостоятельно.

Два пути инжекции

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

• Путь A — только libc (по умолчанию). И зона C, и зона A располагаются в кармане .text libc. Таблица слотов + области CMD + OUTPUT располагаются в секции .hash libc — это унаследованные SysV-хеш-данные, которые ld.so во время выполнения не читает, поскольку вместо них использует .gnu.hash. Когда .hash отсутствует (современный тулчейн Arch), page_inject вместо этого вырезает область слотов из хвоста .eh_frame_hdr, предварительно уменьшив поле fde_count, чтобы unwinder больше не считал освобождённые байты частью индекса бинарного поиска FDE (для любого IP, чей FDE ранее находился в усечённом диапазоне, unwinder прозрачно переходит к линейному сканированию .eh_frame — поведение, предписанное стандартом LSB).

• Путь B — трамплин в libc + payload в ld.so. Некоторые сборки glibc уменьшают карман libc до размера меньше необходимого для полного payload зоны C + зоны A (Ubuntu 24.04 / glibc 2.39 поставляется с карманом в 711 байт). В этом случае page_inject записывает в карман libc 36-байтовый трамплин: он выполняет проверку .bss-ключа в быстром пути внутри libc, а в медленном пути вычисляет базовый адрес ld.so во время выполнения по GOT-слоту libc для _rtld_global (символ на стороне ld.so, который каждая glibc импортирует приватно) и прыгает в вариант зоны C с базовым регистром, расположенный в кармане .text ld.so. Таблица слотов + CMD + OUTPUT + ключ .bss остаются в libc; зона C на стороне ld.so обращается к ним через rbp + offset, после того как трамплин инициализирует rbp = libc_base.

Если не подходит ни одна компоновка, page_inject чисто отказывается от работы, ничего не записывая в libc или ld.so — ни на диск, ни в page-cache.

Обработка пролога read()

Разные версии glibc порождают разные начальные последовательности в read(). Инжектор распознаёт каждую из них, считывает байты, которые вытесняет хук, и эмулирует их в быстром пути зоны C, чтобы однопоточный вызов read() корректно продолжался с read()+N:

Слот эмуляции в быстром пути зоны C рассчитан на самый длинный из известных прологов (8 байт) плюс 5-байтовый rel32-переход; более короткие прологи заполняют последний байт слота NOP-заполнителем, чтобы общая длина слота оставалась постоянной.

Структура файлов

Матрица протестированных и поддерживаемых конфигураций

Эксплойт был проверен по всей цепочке (end-to-end) на следующих дистрибутивах, упакованных в снапшоты контейнеров. Для каждой записи page_inject внедрялся изнутри одного контейнера, и его хук срабатывал в соседнем контейнере, запущенном из того же образа; команды корректно выполнялись через канал page-cache; а unhook чисто восстанавливал состояние страниц libc.

Эксплуатационные заметки

• page_inject намеренно слинкован статически, чтобы собственный процесс атакующего не затрагивался установленным им хуком.
• page_inject распознаёт уже «захваченную» libc (E9 + NOP в прологе read()) и отказывается от повторной инжекции. Если вы находитесь в тестовом окружении и ваш page-cache застрял в таком состоянии, остановите все контейнеры, использующие этот образ, и выполните drop_caches для сброса.