Простір імен IPC

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Огляд

Простір імен IPC ізолює System V IPC objects та POSIX message queues. Це включає сегменти розділеної пам’яті, семафори та черги повідомлень, які інакше були б видимі між несумісними процесами на хості. На практиці це перешкоджає контейнеру випадково підключатися до IPC-об’єктів, що належать іншим workload’ам або хосту.

У порівнянні з mount, PID або user namespaces, про IPC простір імен говорять рідше, але це не означає, що він неважливий. Розділена пам’ять і пов’язані IPC-механізми можуть містити дуже корисний стан. Якщо host IPC namespace буде доступний, workload може отримати видимість об’єктів або даних міжпроцесної координації, які ніколи не планувалося переносити через межу контейнера.

Принцип роботи

Коли runtime створює новий IPC простір імен, процес отримує власний ізольований набір IPC ідентифікаторів. Це означає, що команди на кшталт ipcs показують лише об’єкти, доступні в цьому просторі імен. Якщо ж контейнер приєднується до host IPC namespace, ці об’єкти стають частиною загальної глобальної видимості.

Це особливо важливо в середовищах, де додатки або сервіси інтенсивно використовують розділену пам’ять. Навіть коли контейнер не може безпосередньо вийти через IPC сам по собі, простір імен може leak інформацію або дозволити міжпроцесну взаємодію, що суттєво полегшує подальшу атаку.

Лаб

Ви можете створити приватний простір імен IPC за допомогою:

sudo unshare --ipc --fork bash
ipcs

І порівняйте поведінку під час виконання з:

docker run --rm debian:stable-slim ipcs
docker run --rm --ipc=host debian:stable-slim ipcs

Використання під час виконання

Docker та Podman за замовчуванням ізолюють IPC. Kubernetes зазвичай надає Pod власний IPC namespace, який спільний для контейнерів у тому самому Pod, але за замовчуванням не спільний з хостом. Спільний доступ до IPC з хостом можливий, але його слід розглядати як істотне зменшення ізоляції, а не як незначну опцію виконання.

Помилки конфігурації

Очевидна помилка — --ipc=host або hostIPC: true. Це може робитися для сумісності зі старим ПО або для зручності, але суттєво змінює модель довіри. Інша поширена проблема — просто ігнорування IPC, бо це здається менш драматичним, ніж PID хоста або мережа хоста. Насправді, якщо робоче навантаження працює з браузерами, базами даних, науковими задачами або іншим ПО, що широко використовує спільну пам’ять, поверхня IPC може бути дуже релевантною.

Зловживання

Коли IPC хоста спільний, атакуючий може інспектувати або втручатися в об’єкти спільної пам’яті, отримати нові відомості про поведінку хоста або сусідніх робочих навантажень, або поєднати отриману інформацію з видимістю процесів та можливостями типу ptrace. Спільний доступ до IPC часто є допоміжною вразливістю, а не повним шляхом виходу, але допоміжні вразливості важливі, бо скорочують і стабілізують реальні ланцюги атак.

Першим корисним кроком є перерахувати, які об’єкти IPC взагалі видимі:

readlink /proc/self/ns/ipc
ipcs -a
ls -la /dev/shm 2>/dev/null | head -n 50

Якщо IPC namespace хоста спільно використовується, великі сегменти спільної пам’яті або цікаві власники об’єктів можуть негайно виявити поведінку застосунку:

ipcs -m -p
ipcs -q -p

У деяких середовищах вміст /dev/shm сам по собі leak і може містити імена файлів, артефакти або токени, які варто перевірити:

find /dev/shm -maxdepth 2 -type f 2>/dev/null -ls | head -n 50
strings /dev/shm/* 2>/dev/null | head -n 50

Спільний доступ IPC рідко сам по собі дає миттєвий host root, але може відкривати канали даних та координації, які значно полегшують подальші атаки на процеси.

Повний приклад: /dev/shm Відновлення секретів

Найреалістичнішим повним сценарієм зловживання є крадіжка даних, а не пряме порушення ізоляції. Якщо host IPC або широка конфігурація спільної пам’яті відкриті, чутливі артефакти іноді можна відновити безпосередньо:

find /dev/shm -maxdepth 2 -type f 2>/dev/null -print
strings /dev/shm/* 2>/dev/null | grep -Ei 'token|secret|password|jwt|key'

Наслідки:

  • вилучення секретів або матеріалів сесії, що залишилися в shared memory
  • уявлення про додатки, які наразі активні на хості
  • краще націлювання для подальших PID-namespace або атак на основі ptrace

Отже, спільне використання IPC краще розуміти як підсилювач атак, ніж як автономний примітив виходу з хоста.

Перевірки

Ці команди призначені, щоб відповісти на питання, чи має workload приватний IPC view, чи видимі значущі shared-memory або message objects, і чи сам /dev/shm містить корисні артефакти.

readlink /proc/self/ns/ipc   # Namespace identifier for IPC
ipcs -a                      # Visible SysV IPC objects
mount | grep shm             # Shared-memory mounts, especially /dev/shm

Що тут цікаво:

  • Якщо ipcs -a виявляє об’єкти, що належать несподіваним користувачам або сервісам, простір імен може бути не таким ізольованим, як очікувалося.
  • Великі або незвичайні сегменти спільної пам’яті часто варто дослідити.
  • Широке монтування /dev/shm не є автоматично помилкою, але в деяких середовищах воно leaks імена файлів, артефакти та тимчасові секрети.

IPC рідко отримує такої ж уваги, як більші типи просторів імен, але в середовищах, де його інтенсивно використовують, спільне використання з хостом — це суттєве рішення з безпеки.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks