Memory Tagging Extension (MTE)

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Bilgiler

Memory Tagging Extension (MTE), buffer overflows ve use-after-free gibi bellekle ilgili hataları tespit edip önleyerek yazılımın güvenilirliğini ve güvenliğini artırmak için tasarlanmıştır. MTE, ARM mimarisinin bir parçası olarak her bellek tahsisine küçük bir etiket ekleme ve o belleğe referans veren her işaretçiye karşılık gelen bir etiket iliştirme mekanizması sağlar. Bu yaklaşım, çalışma zamanında yasadışı bellek erişimlerini tespit etmeye olanak vererek bu tür zafiyetlerin rastgele kod yürütmek için kullanılma riskini önemli ölçüde azaltır.

Memory Tagging Extension Nasıl Çalışır

MTE, belleği küçük, sabit boyutlu bloklara ayırır ve her bloğa genellikle birkaç bit büyüklüğünde bir etiket atar.

Bir belleğe işaret eden bir pointer oluşturulduğunda, aynı etiket ona atanır. Bu etiket, işaretçinin kullanılmayan bitlerinde saklanır ve böylece işaretçi ile ilgili bellek bloğu efektif olarak birbirine bağlanmış olur.

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

Bir program belleğe bir işaretçi aracılığıyla eriştiğinde, MTE donanımı işaretçinin etiketi ile bellek bloğunun etiketinin eşleşip eşleşmediğini kontrol eder. Etiketler eşleşmezse, bu bir yasadışı bellek erişimi olduğunu gösterir.

MTE Pointer Etiketleri

Bir pointer içindeki etiketler üst bayttaki 4 bit içinde saklanır:

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

Bu nedenle en fazla 16 farklı etiket değeri mümkündür.

MTE Bellek Etiketleri

Her 16B fiziksel bellek için karşılık gelen bir bellek etiketi bulunur.

Bellek etiketleri ayrılmış bir RAM bölgesinde saklanır (normal kullanım için erişilemez). Her 16B için 4 bitlik etiket tutulması, toplam RAM’in yaklaşık %3üne kadar yer kaplayabilir.

ARM, bu etiketleri ayrılmış RAM bölgesinde işlemek için aşağıdaki talimatları tanıtır:

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
...

Kontrol Modları

Sync

CPU, etiketleri talimatın yürütülmesi sırasında kontrol eder; bir uyuşmazlık olursa bir istisna (SIGSEGV with SEGV_MTESERR) fırlatılır ve hemen hangi talimat ve adresin etkilendiğini bilirsiniz.
Bu en yavaş ama en güvenli moddur çünkü sorunlu load/store engellenir.

Async

CPU etiketleri asenkron olarak kontrol eder ve bir uyuşmazlık bulunduğunda sistem kayıtlarından birindeki istisna bitini setler. Öncekine göre daha hızlıdır fakat uyuşmazlığa sebep olan kesin talimatı belirleyemez ve istisnayı hemen fırlatmaz (SIGSEGV with SEGV_MTEAERR), saldırganın saldırısını tamamlaması için zaman verir.

Mixed

Per-core tercihler (ör. sync, async veya asymm yazmak için /sys/devices/system/cpu/cpu*/mte_tcf_preferred) kernel’lerin per-process istekleri sessizce yükseltmesine veya düşürmesine izin verir, bu yüzden production build’ler genellikle ASYNC isterken yetkili çekirdekler iş yükü izin verdiğinde SYNC zorlar.

Implementation & Detection Examples

Called Hardware Tag-Based KASAN, MTE-based KASAN or in-kernel MTE.
Kernel allocator’ları (ör. kmalloc) bu modülü çağırır; modül kullanılacak etiketi (rastgele) hazırlar, ayrılan kernel alanına ve döndürülen pointer’a iliştirir.

Not: yalnızca istenen boyut için yeterli bellek granüllerini işaretleyecektir (her biri 16B). Yani istenen boyut 35 ise ve 60B’lik bir slab verildiyse, ilk 16*3 = 48B bu etiketle işaretlenecek ve kalan kısım geçersiz etiket (0xE) ile işaretlenecektir.

Etiket 0xF bir match all pointer’dır. Bu pointer’a sahip bir bellek, belleğe erişmek için herhangi bir etiketin kullanılmasına izin verir (hiç uyuşmazlık olmaz). Eğer saldırılan bellek bu etiketi kullanıyorsa bu, MTE’nin bir saldırıyı tespit etmesini engelleyebilir.

Dolayısıyla 0xE ve 0xF rezerve olduğundan etiket üretmek için yalnızca 14 değer kullanılabilir; bu da etiketlerin tekrar kullanılma olasılığını 1/17 -> yaklaşık %7 yapar.

Kernel, invalid tag granule’ına erişirse mismatch tespit edilir. Başka bir bellek konumuna erişirse ve bellek farklı bir etiket içeriyorsa (veya invalid tag ise) yine mismatch tespit edilir. Eğer saldırgan şanslıysa ve bellek aynı etiketi kullanıyorsa tespit edilmez. Olasılık yaklaşık %7’dir.

Başka bir bug, ayrılan belleğin son granülü üzerinde olur. Uygulama 35B istemişse, kendisine 32–48 arası granül verilmiş demektir. Bu yüzden 36–47 arası byte’lar aynı etiketi kullanır ama istenmemişlerdir. Saldırgan bu fazladan byte’lara erişirse, bu tespit edilmez.

kfree() yürütüldüğünde bellek geçersiz bellek etiketiyle yeniden etiketlenir, bu yüzden bir use-after-free durumunda bellek tekrar erişildiğinde mismatch tespit edilir.

Ancak bir use-after-free durumunda aynı chunk tekrar aynı TAG ile yeniden allocate edilirse, saldırgan bu erişimi kullanabilir ve bu tespit edilmez (yaklaşık %7 şans).

Ayrıca yalnızca slab ve page_alloc şu an tagged memory kullanır fakat gelecekte vmalloc, stack ve globals’ta da kullanılacak (videonun çekildiği anda bunlar hâlâ kötüye kullanılabiliyor).

Bir mismatch tespit edildiğinde kernel daha fazla istismarı ve exploit denemelerini engellemek için panic olur (MTE false positive içermez).

Speculative Tag Leakage (TikTag)

TikTag (2024) iki speculative execution gadget’ı (TIKTAG-v1/v2) gösterdi; bunlar herhangi bir adresin 4-bit allocation tag’ini <4 saniyede ve >%95 başarı ile leak edebiliyor. Saldırganın seçtiği cache line’lara spekülatif olarak dokunup prefetch kaynaklı zamanlamaları gözlemleyerek, saldırgan Chrome process’lerine, Android system service’lerine veya Linux kernel’e atanan etiketi derandomize edebilir ve sonra leak edilen değeri taşıyan pointer’lar oluşturabilir. Etiket alanı brute-force ile ortadan kaldırıldığında, olasılıksal granül yeniden kullanım varsayımları (≈7% false-negative oranı) çöker ve klasik heap exploit’leri (UAF, OOB) MTE etkin olsa bile neredeyse %100 güvenilirliğe geri döner. Makale ayrıca leak edilen tag’lerden fake slab’leri retag etmeye pivot yapan PoC exploit’ler sunar; bu da spekülatif side channel’ların donanım etiketleme şemaları için geçerli bir bypass yolu olmaya devam ettiğini gösterir.

Kaynaklar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin