Захисти libc

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

Примусове вирівнювання чанків

Malloc виділяє пам’ять у групах по 8 байт (32-bit) або 16 байт (64-bit). Це означає, що кінець чанків у 32‑бітних системах має вирівнюватися по 0x8, а в 64‑бітних системах — по 0x0. Ця функція безпеки перевіряє, що кожен чанк правильно вирівняний у цих конкретних місцях перед тим, як використовувати вказівник із bin.

Переваги безпеки

Примусове вирівнювання чанків у 64‑бітних системах значно підвищує безпеку Malloc, обмежуючи розміщення фейкових чанків лише до 1 з 16 адрес. Це ускладнює експлуатацію вразливостей, особливо в сценаріях, де користувач має обмежений контроль над вводом значень, що робить атаки складнішими й менш ймовірними для успіху.

  • Fastbin Attack on __malloc_hook

Нові правила вирівнювання в Malloc також блокують класичну атаку, повʼязану з __malloc_hook. Раніше атакуючі могли маніпулювати розмірами чанків, щоб перезаписати цей вказівник-функцію й отримати виконання коду. Тепер сувора вимога вирівнювання гарантує, що такі маніпуляції більше не є життєздатними, закриваючи поширений шлях експлуатації й підвищуючи загальну безпеку.

Примітка: З починаючи з glibc 2.34 легаси-хуки (__malloc_hook, __free_hook тощо) видалені з експортованого ABI. Сучасні експлойти тепер націлені на інші записувані вказівники функцій (наприклад, tcache per-thread struct, vtable-style callbacks) або покладаються на setcontext, _IO_list_all primitives тощо.

Pointer Mangling on fastbins and tcache

Pointer Mangling — це механізм захисту, який використовується для захисту fastbin і tcache Fd pointers в операціях керування памʼяттю. Ця техніка допомагає запобігти певним типам атак на памʼять, зокрема тим, які не вимагають наявності leaked memory information або які маніпулюють місцями памʼяті безпосередньо відносно відомих позицій (relative overwrites).

Суть цієї техніки — формула обфускації:

New_Ptr = (L >> 12) XOR P

  • L — це Storage Location вказівника.
  • P — фактичний fastbin/tcache Fd Pointer.

Причина зсуву бітів місця збереження (L) на 12 біт вправо перед операцією XOR є критичною. Це усуває вразливість, повʼязану з детермінованою природою найменш значущих 12 біт адрес памʼяті, які зазвичай передбачувані через архітектурні обмеження системи. Переміщуючи ці біти, передбачувана частина виходить з рівняння, що підвищує випадковість нового, замаскованого вказівника й, таким чином, захищає від атак, які покладаються на передбачуваність цих бітів.

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

Деманглінг вказівника для отримання оригінальної адреси виконується за тією ж операцією XOR. Тут замаскований вказівник трактують як P у формулі, і при XOR з незмінним місцем збереження (L) відновлюється початковий вказівник. Ця симетрія в манглінгу і деманглінгу гарантує, що система може ефективно кодувати та декодувати вказівники без значного навантаження, водночас суттєво підвищуючи захист від атак, що маніпулюють вказівниками памʼяті.

Переваги безпеки

Pointer mangling має на меті запобігти частковим і повним перезаписам вказівників у керуванні heap, що є значним покращенням безпеки. Ця функція впливає на методи експлуатації кількома способами:

  1. Запобігання байтовим відносним перезаписам (Bye Byte Relative Overwrites): Раніше атакуючі могли змінювати частину вказівника, щоб перенаправити heap чанки в інші місця без точних адрес, що видно в leakless експлоїті House of Roman. З pointer mangling такі відносні перезаписи без heap leak тепер вимагають brute forcing, що значно знижує ймовірність їх успіху.
  2. Підвищена складність атак на tcache bin/fastbin: Звичні атаки, які перезаписують вказівники функцій (наприклад, __malloc_hook) шляхом маніпуляцій із fastbin або tcache записами, ускладнені. Наприклад, атака може включати витік LibC адреси, звільнення чанка в tcache bin, а потім перезапис Fd вказівника, щоб перенаправити його на __malloc_hook для довільного виконання коду. З pointer mangling ці вказівники повинні бути правильно заманглені, що вимагає heap leak для коректної маніпуляції, підвищуючи бар’єр для експлуатації.
  3. Вимога heap leaks для неналежних місць (non-heap locations): Створення фейкового чанка в не-heap зонах (наприклад, на stack, у .bss section або PLT/GOT) тепер також вимагає heap leak через необхідність pointer mangling. Це ускладнює експлуатацію цих ділянок, аналогічно до вимог при маніпуляції LibC адресами.
  4. Утруднення витоку heap адрес: Pointer mangling обмежує корисність Fd вказівників у fastbin і tcache бінях як джерел для heap address leaks. Проте вказівники в unsorted, small і large bins залишаються немангленими й тому все ще придатні для витоків адрес. Це змушує атакуючих досліджувати ці біні для отримання експлуатованої інформації, хоча деякі техніки можуть дозволити деманглінг вказівників перед leak, але з певними обмеженнями.

Safe-Linking Bypass (page-aligned leak scenario)

Навіть при увімкненому safe-linking (glibc ≥ 2.32), якщо ви можете leak замангленого вказівника і як пошкоджений чанк, так і victim chunk знаходяться на одній 4KB сторінці, оригінальний вказівник можна відновити, маючи лише page offset:

// leaked_fd is the mangled Fd read from the chunk on the same page
uintptr_t l = (uintptr_t)&chunk->fd;           // storage location
uintptr_t original = (leaked_fd ^ (l >> 12));  // demangle

This відновлює Fd і дозволяє класичне tcache/fastbin poisoning. Якщо chunks розташовані на різних pages, brute-forcing 12-bit page offset (0x1000 possibilities) часто здійсненний, коли allocation patterns детерміновані або коли краші допустимі (наприклад, CTF-style exploits).

Demangling Pointers with a Heap Leak

Caution

Для кращого пояснення процесу дивіться оригінальний допис тут.

Algorithm Overview

The formula used for mangling and demangling pointers is:

New_Ptr = (L >> 12) XOR P

Де L — місце збереження, а P — Fd pointer. Коли L зміщується праворуч на 12 біт, воно відкриває найбільш значущі біти P, через природу операції XOR, яка дає 0 при XOR-уванні однакових бітів.

Ключові кроки алгоритму:

  1. Initial Leak of the Most Significant Bits: XOR-уючи зсунуте L з P, ви фактично отримуєте верхні 12 біт P, тому що зсунута частина L буде нульовою, залишаючи відповідні біти P незмінними.
  2. Recovery of Pointer Bits: Оскільки XOR є обертовим, знаючи результат і один із операндів, можна обчислити інший операнд. Це властивість використовується для відновлення повного набору бітів P шляхом послідовного XOR-ування відомих наборів бітів з частинами зміненого вказівника.
  3. Iterative Demangling: Процес повторюється, кожного разу використовуючи нововиявлені біти P з попереднього кроку для декодування наступного сегмента зміненого вказівника, доки всі біти не будуть відновлені.
  4. Handling Deterministic Bits: Останні 12 біт L втрачаються через зсув, але вони детерміновані і можуть бути реконструйовані після процесу.

Реалізацію цього алгоритму можна знайти тут: https://github.com/mdulin2/mangle

Pointer Guard

Pointer guard — це техніка зниження ризику експлуатації (exploit mitigation), яка використовується в glibc для захисту збережених function pointers, особливо тих, що реєструються викликами бібліотеки, такими як atexit(). Цей захист передбачає перемішування вказівників шляхом XOR-ування їх з секретом, збереженим у thread data (fs:0x30), і застосування бітового обертання. Механізм спрямований на запобігання захопленню керування шляхом перезапису function pointers.

Bypassing Pointer Guard with a leak

  1. Understanding Pointer Guard Operations: Перемішування (mangling) вказівників виконується за допомогою макроса PTR_MANGLE, який XOR-ує вказівник з 64-бітним секретом, а потім виконує left rotation на 0x11 біт. Зворотна операція для відновлення оригінального вказівника обробляється PTR_DEMANGLE.
  2. Attack Strategy: Атака базується на підході known-plaintext, де атакувальнику потрібно знати як оригінальну, так і змінену версії вказівника, щоб вивести секрет, використаний для mangling.
  3. Exploiting Known Plaintexts:
  • Identifying Fixed Function Pointers: Досліджуючи код glibc або ініціалізовані таблиці function pointers (наприклад, __libc_pthread_functions), атакувальник може знайти передбачувані function pointers.
  • Computing the Secret: Використовуючи відомий function pointer, такий як __pthread_attr_destroy, і його змінену версію з таблиці function pointers, секрет можна обчислити шляхом зворотного обертання (right rotation) зміненого вказівника і подальшого XOR-ування з адресою функції.
  1. Alternative Plaintexts: Атакувальник також може експериментувати з mangling вказівників відомими значеннями, такими як 0 або -1, щоб перевірити, чи породжують вони впізнавані патерни в пам’яті, що потенційно відкриває секрет при знаходженні таких патернів у дампах пам’яті.
  2. Practical Application: Після обчислення секрету атакувальник може маніпулювати вказівниками контрольовано, фактично обходячи Pointer Guard у багатопотоковому застосунку за наявності знання базової адреси libc і можливості читати arbitrary memory locations.

GLIBC Tunables & Recent Loader Bugs

Динамічний loader розбирає GLIBC_TUNABLES до запуску програми. Помилки парсингу тут безпосередньо впливають на libc ще до того, як більшість mitigations вступлять в силу. Баг 2023 року “Looney Tunables” (CVE-2023-4911) є прикладом: надто довге значення GLIBC_TUNABLES переповнює внутрішні буфери в ld.so, що дозволяє privilege escalation на багатьох дистрибутивах у поєднанні з SUID бінарями. Для експлуатації достатньо підготувати environment і багаторазово викликати цільову бінару; pointer guard або safe-linking не захищають, оскільки корупція відбувається в лоадері до налаштування heap.

References

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