Memory Tagging Extension (MTE)

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Podstawowe informacje

Memory Tagging Extension (MTE) ma na celu zwiększenie niezawodności i bezpieczeństwa oprogramowania poprzez wykrywanie i zapobieganie błędom związanym z pamięcią, takich jak buffer overflows i use-after-free. MTE, jako część architektury ARM, zapewnia mechanizm do dołączania małego taga do każdej alokacji pamięci oraz odpowiedniego taga do każdego wskaźnika wskazującego na tę pamięć. Takie podejście pozwala na wykrywanie nielegalnych dostępów do pamięci w czasie wykonywania, znacząco zmniejszając ryzyko wykorzystania takich podatności do wykonania dowolnego kodu.

Jak działa Memory Tagging Extension

MTE działa poprzez dzielenie pamięci na małe, stałej wielkości bloki, z przypisanym do każdego bloku tagiem, zazwyczaj o rozmiarze kilku bitów.

Kiedy tworzony jest wskaźnik wskazujący na tę pamięć, otrzymuje ten sam tag. Tag jest przechowywany w nieużywanych bitach wskaźnika pamięci, skutecznie łącząc wskaźnik z odpowiadającym mu blokiem pamięci.

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

Gdy program uzyskuje dostęp do pamięci za pomocą wskaźnika, sprzęt MTE sprawdza, czy tag wskaźnika pasuje do taga bloku pamięci. Jeśli tagi nie pasują, wskazuje to na nielegalny dostęp do pamięci.

MTE Pointer Tags

Tagi wewnątrz wskaźnika są przechowywane w 4 bitach w najwyższym bajcie:

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

Daje to zatem możliwość użycia do 16 różnych wartości tagów.

MTE Memory Tags

Co każde 16B pamięci fizycznej ma odpowiadający mu tag pamięci.

Tagi pamięci są przechowywane w wydzielonym regionie RAM (niedostępnym dla normalnego użycia). Posiadanie 4-bitowych tagów dla każdego 16B pamięci powoduje zajęcie do 3% RAM.

ARM wprowadza następujące instrukcje do manipulowania tymi tagami w wydzielonym obszarze pamięci 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
...

Tryby sprawdzania

Sync

CPU sprawdza tagi podczas wykonywania instrukcji, jeśli wystąpi niezgodność, zgłasza wyjątek (SIGSEGV z SEGV_MTESERR) i od razu znasz dokładną instrukcję i adres.
To jest najwolniejsze i najbezpieczniejsze, ponieważ offending load/store jest zablokowany.

Async

CPU sprawdza tagi asynchronicznie, i gdy wykryje niezgodność ustawia bit wyjątku w jednym z rejestrów systemowych. Jest to szybsze niż poprzednie, ale nie jest w stanie wskazać dokładnej instrukcji powodującej niezgodność i nie zgłasza wyjątku natychmiast (SIGSEGV z SEGV_MTEAERR), dając napastnikowi trochę czasu na dokończenie ataku.

Mixed

Preferencje na poziomie rdzenia (np. zapis sync, async lub asymm do /sys/devices/system/cpu/cpu*/mte_tcf_preferred) pozwalają jądrom bezgłośnie podnosić lub obniżać żądania przypisane do procesu, więc buildy produkcyjne zwykle żądają ASYNC, podczas gdy uprzywilejowane rdzenie wymuszają SYNC, gdy obciążenie na to pozwala.

Implementacja i przykłady wykrywania

Nazywane Hardware Tag-Based KASAN, MTE-based KASAN lub in-kernel MTE.
Alokatory jądra (jak kmalloc) będą wywoływać ten moduł, który przygotuje tag do użycia (losowo), przypisze go do zaalokowanej przestrzeni jądra i do zwracanego wskaźnika.

Zwróć uwagę, że oznaczy tylko wystarczającą liczbę granulek pamięci (po 16B każda) dla żądanego rozmiaru. Tak więc jeśli żądany rozmiar wynosił 35 i przydzielono slab 60B, oznaczy pierwsze 16*3 = 48B tym tagiem, a reszta zostanie oznaczona tzw. invalid tag (0xE).

Tag 0xF is the match all pointer. Pamięć z tym wskaźnikiem pozwala użyć dowolnego tagu do dostępu do jej zawartości (brak niezgodności). To może uniemożliwić MTE wykrycie ataku, jeśli ten tag jest używany w atakowanej pamięci.

Dlatego istnieje tylko 14 wartości, które można użyć do generowania tagów, ponieważ 0xE i 0xF są zarezerwowane, co daje prawdopodobieństwo ponownego użycia tagów równe 1/17 -> około 7%.

Jeśli jądro uzyska dostęp do granulki z invalid tag, niezgodność zostanie wykryta. Jeśli uzyska dostęp do innego obszaru pamięci i pamięć ma inny tag (lub invalid tag), niezgodność również zostanie wykryta. Jeśli napastnik ma szczęście i pamięć używa tego samego tagu, nie zostanie wykryta. Szanse wynoszą około 7%.

Inny błąd występuje w ostatniej granulce zaalokowanej pamięci. Jeśli aplikacja zażądała 35B, przydzielono granulke od 32 do 48. W związku z tym bajty od 36 do 47 używają tego samego tagu, ale nie zostały żądane. Jeśli napastnik uzyska dostęp do tych dodatkowych bajtów, nie jest to wykrywane.

Kiedy wywoływane jest kfree(), pamięć jest ponownie otagowana invalid memory tag, więc w przypadku use-after-free, gdy pamięć zostanie ponownie odczytana, niezgodność zostanie wykryta.

Jednak w przypadku use-after-free, jeśli ten sam chunk zostanie ponownie zaalokowany z TYM SAMYM tagiem co wcześniej, napastnik będzie mógł użyć tego dostępu i nie zostanie to wykryte (około 7% szans).

Co więcej, tylko slab i page_alloc używają tagowanej pamięci, ale w przyszłości będzie to także stosowane w vmalloc, stack i globals (w chwili nagrania wideo można je nadal nadużywać).

Kiedy wykryta zostanie niezgodność, jądro wywoła panic aby zapobiec dalszemu wykorzystaniu i kolejnym próbom exploitu (MTE nie ma false positives).

Speculative Tag Leakage (TikTag)

TikTag (2024) demonstrated two speculative execution gadgets (TIKTAG-v1/v2) able to leak the 4-bit allocation tag of any address in <4 seconds with >95% success. By speculatively touching attacker-chosen cache lines and observing prefetch-induced timing, an attacker can derandomize the tag assigned to Chrome processes, Android system services, or the Linux kernel and then craft pointers carrying the leaked value. Once the tag space is brute-forced away, the probabilistic granule reuse assumptions (≈7% false-negative rate) collapse and classic heap exploits (UAF, OOB) regain near-100% reliability even when MTE is enabled. The paper also ships proof-of-concept exploits that pivot from leaked tags to retagging fake slabs, illustrating that speculative side channels remain a viable bypass path for hardware tagging schemes.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks