Memory Tagging Extension (MTE)

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

Основна інформація

Memory Tagging Extension (MTE) призначена для підвищення надійності та безпеки програмного забезпечення шляхом виявлення та запобігання помилкам, пов’язаним із пам’яттю, такими як buffer overflows та use-after-free vulnerabilities. MTE, як частина архітектури ARM, надає механізм додавання невеликого тегу до кожного виділення пам’яті і відповідного тегу до кожного вказівника, що посилається на цю пам’ять. Такий підхід дозволяє виявляти незаконні доступи до пам’яті під час виконання, суттєво знижуючи ризик використання таких вразливостей для виконання довільного коду.

How Memory Tagging Extension Works

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

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

https://www.youtube.com/watch?v=UwMt0e_dC_Q

Коли програма звертається до пам’яті через вказівник, апаратна частина MTE перевіряє, чи тег вказівника збігається з тегом блоку пам’яті. Якщо теги не збігаються, це вказує на незаконний доступ до пам’яті.

MTE Pointer Tags

Теги всередині вказівника зберігаються в 4 бітах у верхньому байті:

https://www.youtube.com/watch?v=UwMt0e_dC_Q

Отже, це дозволяє мати до 16 різних значень тегів.

MTE Memory Tags

Кожні 16B фізичної пам’яті мають відповідний memory tag.

Теги пам’яті зберігаються в виділеному регіоні RAM (не доступному для звичайного використання). Маючи 4-bit теги для кожних 16B пам’яті, це займає до 3% від RAM.

ARM вводить наступні інструкції для маніпуляції цими тегами у виділеному регіоні RAM:

STG [<Xn/SP>], #<simm>    Store Allocation (memory) Tag
LDG <Xt>, [<Xn/SP>]       Load Allocatoin (memory) Tag
IRG <Xd/SP>, <Xn/SP>      Insert Random [pointer] Tag
...

Checking Modes

Sync

The CPU перевіряє теги під час виконання інструкції, якщо є невідповідність — виникає виняток (SIGSEGV з SEGV_MTESERR) і ви одразу дізнаєтеся точну інструкцію та адресу.
Це найповільніший і найбезпечніший режим, оскільки проблемне load/store блокується.

Async

The CPU перевіряє теги асинхронно, і при виявленні невідповідності встановлює біт винятку в одному з системних регістрів. Це швидше, ніж попередній режим, але не може вказати точну інструкцію, що спричинила невідповідність, і не викликає виняток негайно (SIGSEGV з SEGV_MTEAERR), даючи атакуючому трохи часу для завершення атаки.

Mixed

Per-core preferences (for example writing sync, async or asymm to /sys/devices/system/cpu/cpu*/mte_tcf_preferred) дозволяють ядру безшумно підвищувати або знижувати запити процесів, тому в продакшні зазвичай запитують ASYNC, тоді як привілейовані ядра змушують SYNC, коли навантаження це дозволяє.

Implementation & Detection Examples

Called Hardware Tag-Based KASAN, MTE-based KASAN or in-kernel MTE.
Ядрові алокатори (наприклад kmalloc) будуть викликати цей модуль, який підготує тег для використання (рандомно), прив’яже його до виділеної ядрової пам’яті і до повернутого вказівника.

Зауважте, що він позначить лише стільки гранул пам’яті (по 16B кожна), скільки потрібно для запитаного розміру. Тому якщо запитували 35B, а виділено slab розміром 60B, він позначить перші 16*3 = 48B цим тегом, а решту буде позначено так званим invalid tag (0xE).

Тег 0xF — це match all pointer. Пам’ять з таким тегом дозволяє використовувати будь-який тег для доступу до неї (немає невідповідностей). Це може перешкодити MTE виявити атаку, якщо в атакованій пам’яті використовується цей тег.

Отже, доступно лише 14 значень для генерації тегів, оскільки 0xE та 0xF зарезервовані, що дає ймовірність повторного використання тегів 1/17 -> приблизно 7%.

Якщо ядро звертається до гранулі з invalid tag, відбудеться невідповідність і вона буде виявлена. Якщо воно звертається до іншої локації пам’яті і ця пам’ять має інший тег (або invalid tag), невідповідність також буде виявлена. Якщо атакуючому пощастить і пам’ять використовує той самий тег, це не буде виявлено. Шанси — приблизно 7%.

Інша помилка виникає в останній гранулі виділеної пам’яті. Якщо додаток запросив 35B, йому виділили гранулю з 32 до 48. Отже байти з 36 по 47 використовують той самий тег, але вони не були запитані. Якщо атакуючий звертається до цих зайвих байтів, це не виявляється.

Коли виконується kfree(), пам’ять ретегується з invalid memory tag, тому при use-after-free, коли пам’ять доступна повторно, невідповідність буде виявлена.

Проте при use-after-free, якщо та сама частина знову перерахується з ТИМ САМИМ тегом, атакуючий зможе скористатися цим доступом і це не буде виявлено (приблизно 7% шансів).

Крім того, лише slab and page_alloc наразі використовують теговану пам’ять, але в майбутньому це також може бути застосовано до vmalloc, stack і globals (на момент запису відео їх ще можна зловживати).

Коли виявляється невідповідність, ядро панікує, щоб запобігти подальшій експлуатації і повторним спробам (MTE не дає false positives).

Speculative Tag Leakage (TikTag)

TikTag (2024) продемонстрував два гаджети speculative execution (TIKTAG-v1/v2), здатні leak 4-бітний allocation tag будь-якої адреси за <4 секунд з >95% успіхом. Послідовно торкаючись cache lines, обраних атакуючим, і спостерігаючи таймінги, індуковані prefetch, атакуючий може дерендомізувати тег, призначений процесам Chrome, службам Android або ядру Linux, а потім скрафтити вказівники з витеклим значенням. Після того, як простір тегів буде перебраний brute-force, імовірні припущення про повторне використання гранул (≈7% false-negative rate) руйнуються і класичні heap-експлойти (UAF, OOB) відновлюють майже 100% надійність навіть при увімкненому MTE. У статті також є proof-of-concept експлойти, які переходять від leaked tags до ретегування фейкових slab-ів, ілюструючи, що speculative side channels залишаються життєздатним шляхом обходу апаратних схем тегування.

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