UTS Namespace

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

Огляд

UTS namespace ізолює hostname та NIS domain name, які бачить процес. На перший погляд це може здатися тривіальним порівняно з mount, PID або user namespaces, але саме це частково створює враження, що container є окремим хостом. Всередині namespace робоче навантаження може бачити і іноді змінювати hostname, який є локальним для цього namespace, а не глобальним для машини.

Саме по собі це зазвичай не є основною частиною історії про breakout. Однак якщо host UTS namespace буде розділено, процес із достатніми привілеями може впливати на налаштування, пов’язані з ідентифікацією хоста, що може мати наслідки в операційній площині і інколи — з погляду безпеки.

Лабораторія

Ви можете створити UTS namespace за допомогою:

sudo unshare --uts --fork bash
hostname
hostname lab-container
hostname

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

Runtime Usage

Звичайні контейнери отримують ізольований простір імен UTS. Docker і Podman можуть приєднатися до простору імен UTS хоста через --uts=host, і схожі схеми спільного використання хоста можуть з’являтися в інших runtime та системах оркестрації. Однак більшість часу приватна UTS-ізоляція просто є частиною стандартного налаштування контейнера і потребує мало уваги оператора.

Security Impact

Хоча простір імен UTS зазвичай не є найнебезпечнішим для спільного використання, він все одно впливає на цілісність межі контейнера. Якщо простір імен UTS хоста відкритий і процес має необхідні привілеї, він може змінювати інформацію, пов’язану з ідентифікацією хоста (наприклад, ім’я хоста). Це може вплинути на моніторинг, логування, операційні припущення або скрипти, що приймають рішення про довіру на основі даних про ідентичність хоста.

Abuse

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

readlink /proc/self/ns/uts
hostname
cat /proc/sys/kernel/hostname

Якщо контейнер також має необхідні привілеї, перевірте, чи можна змінити hostname:

hostname hacked-host 2>/dev/null && echo "hostname change worked"
hostname

Це передусім проблема цілісності та операційного впливу, а не повний escape, але це все одно показує, що контейнер може безпосередньо впливати на глобальну властивість хоста.

Наслідки:

  • підроблення ідентичності хоста
  • заплутування логів, моніторингу або автоматизації, які покладаються на hostname
  • зазвичай саме по собі не є повним escape, якщо не поєднане з іншими вразливостями

У Docker-style середовищах корисний шаблон виявлення на стороні хоста:

docker ps -aq | xargs -r docker inspect --format '{{.Id}} UTSMode={{.HostConfig.UTSMode}}'

Контейнери, що показують UTSMode=host, ділять UTS-простір імен хоста і їх слід ретельніше перевірити, якщо вони також мають capabilities, які дозволяють викликати sethostname() або setdomainname().

Перевірки

Ці команди достатні, щоб визначити, чи має workload власний вигляд hostname, чи спільно використовує UTS-простір імен хоста.

readlink /proc/self/ns/uts   # UTS namespace identifier
hostname                     # Hostname as seen by the current process
cat /proc/sys/kernel/hostname   # Kernel hostname value in this namespace
  • Збіг ідентифікаторів namespace з процесом хоста може свідчити про те, що UTS спільно використовується з хостом.
  • Якщо зміна hostname впливає не лише на сам container, це означає, що workload має більший вплив на ідентичність хоста, ніж має.
  • Зазвичай це має нижчий пріоритет, ніж проблеми з PID, mount або user namespace, але все одно підтверджує, наскільки ізольований процес насправді.

У більшості середовищ UTS namespace найкраще розглядати як допоміжний рівень ізоляції. Це рідко перше, що ви перевіряєте під час breakout, але воно все одно є частиною загальної узгодженості й безпеки подання container.

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