Skip to content

Pointer Authentication (PAC)

ARMv8.3-A Pointer Authentication, pointer'ları kullanılmayan üst bitlerinde saklanan key'li kriptografik bir MAC ile imzalar; böylece ile oynanmış code veya data pointer'ları kullanılmadan önce authentication'da başarısız olur — ROP/JOP ve pointer-corruption saldırılarına karşı çıtayı yükseltir.

Mechanism

Kapsam farkı

Bu not generic ARMv8.3-A mimarisini ele alır (QARMA cipher, ARMv8.6 FPAC, PACStack/PARTS/PACtight hardened şemaları). Apple'ın platforma özgü sertleştirilmiş arm64e konuşlandırması — per-boot key re-randomization ve Project Zero iPhone XS pipeline analizi — için bkz. PAC (arm64e Pointer Authentication).

Sınır neden tutuyor

64-bit bir virtual address bitlerinin yalnızca bir alt kümesini kullanır ve her pointer'ın tepesinde boş bir alan bırakır. PAC o alanı bir Pointer Authentication Code ile doldurur: secret 128-bit bir key ile key'lenmiş, hafif tweakable bir cipher (QARMA) kullanılarak (pointer value, 64-bit context/modifier) üzerinde hesaplanan kesilmiş bir MAC.

Mimari beş key sağlar — instruction/code pointer'ları için iki tane (APIAKey, APIBKey), data pointer'ları için iki tane (APDAKey, APDBKey) ve bir general key (APGAKey). Bir sign instruction'ı (PACIA, PACIB, PACDA, …) PAC'i ekler; bir authenticate instruction'ı (AUTIA, AUTIB, …) onu yeniden hesaplar ve kontrol eder, başarıda kullanılabilir bir pointer'ı geri yükler veya başarısızlıkta onu poison'lar (böylece sonraki bir dereference fault verir). XPAC* bir PAC'i kontrol etmeden çıkarır.

Sınır tutar çünkü korunan bir pointer'ı bozan bir saldırgan, secret key olmadan yeni değer için geçerli bir PAC üretemez. Context/modifier her PAC'i bir kullanım site'ına bağlar (örn. bir return address için stack-pointer değeri); geçerli şekilde imzalanmış bir pointer'ın farklı bir slot'a replay edilmesini engeller. Bu, forward-edge (indirect call/branch) ve backward-edge (return address) integrity'sini ucuza, hardware'de verir. Temel kayıt için ARM Pointer Authentication'a ve Apple'ın hardened konuşlandırması için examining PAC on the iPhone XS'e bakın.

Walkthrough

Yüksek seviyeli, kavramsal (ARM/Qualcomm belgelerinden ve herkese açık araştırmalardan):

  1. Üretimde imzala. Function girişinde compiler PACIASP emit eder (LR'deki return address'i context olarak SP ile imzala); imzalanmış bir code pointer için uygun bir modifier ile bir PAC* emit eder.
  2. Store/transit. İmzalanmış pointer, PAC'i üst bitlerinde olacak şekilde bellekte yaşar.
  3. Kullanımda authenticate et. Bir return (RETAA/RETAB) veya indirect branch (BRAA/BLRAA) öncesinde CPU authenticate eder; bir uyumsuzluk pointer'ı poison'lar ve sonraki fetch fault verir.
  4. Apple hardening'i (A12+). Exception level başına farklı key'ler (EL0 vs EL1); böylece userspace kernel-imzalı pointer'ları forge edemez; key'ler çeşitlendirilir ve hardware-managed register'larda tutulur; SCTLR_EL1'de key başına enable bitleri.
Sign / authenticate taslağı 

PACIASP            ; sign LR using SP as context (function prologue)
; ... function body ...
RETAB              ; authenticate-and-return; poisons LR if tampered
Yalnızca kavramsal — key materyali, gadget chain'leri veya offset'ler verilmez.

Bilinen bypass sınıfları

PAC eksiksiz bir CFI değildir. Herkese açık araştırmalar şunları gösterir: signing gadget/oracle'lar (victim'i saldırgan-seçimi bir pointer imzalamaya zorlama, örn. tarihsel AUTIA→PACIZA dizisi) — bkz. PAC signing-oracle reuse; PAC-verification sonuçlarını leak eden PACMAN speculative side channel'ı — bkz. PACMAN; yeniden denemelerin ucuz olduğu yerde küçük PAC alanının brute force'u; ve context'ler benzersiz olmadığında cross-key / cross-context reuse. Hardened şemalar (PACStack, PARTS, PACtight), replay boşluklarını kapatmak için context seçimini sıkılaştırır.

Detection

  • Tekrarlanan PAC-failure fault'ları (poison'lanmış-pointer dereference abort'ları, ARMv8.6 fault-on-fail'de FPAC trap'leri) güçlü bir tamper / exploitation sinyalidir — sessizce kurtulmak yerine onları crash telemetrisinde yüzeye çıkarın.
  • Poison'lanmış-pointer imzalarına sahip process crash patlamaları PAC brute-force'una işaret edebilir.
  • Apple platformlarında, authentication başarısızlıklarına atıf yapan kernel panic'leri.

Mitigation

  • Return address'leri ve code pointer'larını imzalayan bir toolchain ile PAC konuşlandırın (-mbranch-protection=pac-ret/standard; tam PACBTI için BTI ile birleştirin). Replay'i önlemek için context'leri pointer sınıfı/site başına benzersiz tutun.
  • Fault-on-authentication'ı (ARMv8.6 FPAC) benimseyin; böylece forge edilmiş bir pointer, daha sonraki, saldırganın etkilediği bir dereference yerine AUT* instruction'ında fault verir.
  • Key maruziyetini sınırlamak için EL başına / process başına key çeşitlendirmesi (Apple'ın yaptığı gibi).
  • Uyarılar: PAC, hem keyfi bellek erişimine hem de kullanılabilir bir signing gadget'a veya speculation oracle'ına sahip bir saldırganı durduramaz; onu MTE, CFI ve shadow stack'lerin yanında bir katman olarak ele alın.

References