Skip to content

MTE As Implemented (Project Zero MTE analysis)

Mark Brand'in Project Zero çalışması: Memory Tagging Extension'ın gerçekte konuşlandırıldığı haliyle nasıl davrandığı — synchronous MTE güçlü bir bariyer, ama asynchronous MTE bir "soft mitigation"a iner ve known-tag / unknown-tag muhakemesi artı software boşlukları exploitation window'ları bırakır.

Mechanism

Sınır nerede zayıflıyor

MTE prensipte sağlamdır, ama güvenlik değeri reporting mode'una ve onu çevreleyen yazılıma bağlıdır. Brand'in analizi iki rejimi ayırır:

  • Sync-MTE — bir tag mismatch precise biçimde fault'lar ve erişimi bastırır. Doğru tag'i zaten bilmeyen bir saldırganın deneme başına yalnızca ~1/16 şansı vardır ve ilk yanlış tahminde yakalanır. Güçlü durum budur.
  • Async-MTE — mismatch eden erişim tamamlanır; fault yalnızca flag'lenir ve sonra iletilir (tipik olarak kernel'e dönüşte / sonraki timer tick'inde). Bu, kesin bir durdurmayı bir race'e çevirir: exploit, ertelenen kontrol iletilmeden önce işini bitirirse, corruption zaten gerçekleşmiştir.

İki saldırgan zihinsel modeli izler. Known-tag: target granule'ün tag'ini leak et ya da başka şekilde öğren, sonra eşleşen bir pointer hazırla — hiç fault yok. Unknown-tag: tahmin et; sync-MTE altında yanlış bir tahmin ölümcüldür, ama async-MTE altında bir thread devam edebilir ve ertelenen iletim penceresi genişletilebilir (örn. fault'layan thread'de syscall'lardan kaçınarak ya da corrupting erişimi, saldırganın async failure'ına müdahale edilmemesini ayarladığı farklı bir thread'den sürerek). Brand'in 2023 analizi o tarihte sıradan Spectre'nin ötesinde MTE'ye özgü bir speculative side channel bilinmediğini bildirir — ve MTE'nin speculative tag read'leri kasıtlı olarak engellememesi gerektiğini, aksi takdirde kendisinin bir tag-check oracle'ı haline geleceğini not eder. Not (post-2023): Brand'in bu değerlendirmesi 2024'te TikTag (Kim et al., arXiv:2406.08719) tarafından geçersiz kılınmıştır — TikTag, tam da bu tehlikeyi somutlaştıran, tag'leri saniyeler içinde deterministik biçimde sızdıran MTE'ye özgü bir speculative tag-check oracle'ı gösterir ve MTE'nin ~1/16 probabilistik varsayımını çökertir.

Walkthrough

Kavramsal, kamuya açık write-up'tan — hiçbir exploit primitive'i yok.

1. Mode'u belirle. Target'ın sync, async ya da asymmetric MTE çalıştırıp çalıştırmadığını sapta. Güvenlik neredeyse tamamen buna bağlıdır.

2. Mimariyi değil, tag'i yen. Ya tag'i elde et (known-tag, bir leak/oracle yoluyla) ki erişimler eşleşsin, ya da async erteleme penceresi içinde çalış (unknown-tag) ki nihai fault önemini yitirecek kadar geç gelsin.

3. Pencereyi genişlet / atlat. Brand, async durumuna yardımcı olan software boşluklarını öne çıkarır, örn.:

- async failures from one thread may not stop *other* threads mid-exploit
- kernel paths returning EFAULT (not SIGSEGV) on a tag failure can act as oracles
- a first-chance fault handler that returns "handled" suppresses the kill
Timing neden önemli

Brand, tipik bir timer tick (örn. CONFIG_HZ_250) ile bir async-MTE exploit'inin yüksek güvenilirliğe ulaşmak için kabaca ~0.2 ms içinde tamamlanması gerektiğini tahmin eder — sıkı ama ulaşılabilir bir race, ki bu da tam olarak async-MTE'yi neden bir "soft mitigation" olarak sınıflandırdığının nedenidir.

Sync ile async arasındaki fark her şeydir

Başlıca defansif çıkarım: corrupting bir thread'in kesintiye uğramasını engelleyebilen ya da işi async failure'ları iletilmeyen thread'lere zorlayabilen bir saldırgan, async-MTE'yi bir probabilistik hız kesici gibi görebilir. Sync-MTE bu kaçış kapılarını sunmaz.

Detection

  • Crash etmeyen async tag fault'ları. SEGV_MTEAERR olaylarını gösteren telemetry ya da async tag failure'larından sonra hayatta kalan process'ler, istismar edilebilir erteleme pencerelerini gösterir — process ölmese bile araştır.
  • Tag-check fault'larını yutan custom/first-chance fault handler'lar ("handled" döndürerek) bir alarm işaretidir; tagged process'lerde SIGSEGV'i araya giren kodu izle.
  • Tagged user pointer'larında tekrar tekrar isabet alan EFAULT-döndüren kernel yolları tag-probing oracle'ları olabilir — syscall hata pattern'lerini izle.
  • Bir allocation'a karşı tag-guessing patlamaları, MTE tag brute-force'a benzer.

Mitigation

  • Güvenlik sınırlarında synchronous MTE konuşlandır. Async/asymmetric, precision'ı performans için takas eder ve bu analize göre garantiyi maddi olarak zayıflatır. Kernel/userspace trust kenarı için sync'i tercih et.
  • Software boşluklarını kapat: async failure'ların yalnızca bir thread'e sinyal vermek yerine tüm process'i sonlandırdığından emin ol, tag fault'larını bastıran handler'lardan kaçın ve tag-check sonuçlarını return code'lar üzerinden leak eden kernel hata yollarını denetle.
  • Savunmaları birleştir. MTE tek başına probabilistiktir; allocator hardening, PAC tabanlı control-flow integrity ve tag-leak hardening ile birlikte kullan. Enhanced MTE (memory-integrity-enforcement-enhanced-mte), Apple'ın tam da bu "as-implemented" zayıflıklarına yanıtıdır.
  • Residual risk: leak'ler yoluyla known-tag bypass, async erteleme race'leri ve doğal ~1/16 collision, mükemmel konfigürasyonla bile kalır.

References