Pointer authentication code

개요

Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 하드웨어 보안 기법으로, 포인터를 사용하기 전에 이를 인증하여 메모리 안전성을 보장한다. PAC는 Cherry와 유사한 capability-based isolation 환경을 제공하여, Application과 Kernel 모두에서 포인터 무결성을 보장받을 수 있다. 이는 특히 Return-Oriented Programming (ROP), Use-After-Free(UAF), 버퍼 오버플로우 등 현대의 다양한 메모리 공격 기법에 대한 효과적인 방어 수단으로 활용된다.

PAC

Return oriented programming과 같은 공격을 방어하기 위해, 하드웨어 수준에서 Pointer address의 무결성(Integrity)를 검증하는 SFI(Software Fault Isolation) 방식을 제공한다. 이 방식을 통해 포인터가 메모리 접근 전에 정당한지를 하드웨어가 판단하고, 비정상일 경우 접근을 차단한다.

PAC는 포인터가 생성될 때, 사용된 콘텍스트(예: 함수 호출 시의 base pointer, stack pointer 등)와 암호화된 비밀 키를 바탕으로 Message authentication code를 생성하고, 포인터의 상위 비트에 이 정보를 삽입한다. 이후 포인터가 다시 사용될 때, 동일한 키와 콘텍스트를 통해 무결성 확인을 수행하며, 불일치 시 하드웨어 fault를 발생시킨다. 이러한 방식은 특히 ROP chain 탐지, Spatial 및 Temporal memory corruption 예방에 효과적이다.

PAC Instruction

<function prologue>
  paciasp                 ; sign (lr=x30) - SP를 기반으로 PAC 생성
  stp fp, lr, [sp, #0]    ; frame pointer와 link register를 저장
<function body>
<function epilogue>
  ldp fp, lr, [sp, #0]    ; 저장된 값 복원
  autiasp                 ; authentication
  ret                     ; 함수 복귀

• PAC_A_B: 레지스터 B에 있는 포인터에 대해 A 키를 사용하여 PAC를 생성. 예: PACIASP는 Instruction key (IA)로 SP 기반 인증.
• AUT_A x: A 키를 사용해 x 레지스터의 포인터 인증을 수행. 실패 시 fault 발생.
• XPAC x: 인증 실패 시 PAC를 제거해 포인터를 복원(의심 상황 진단용으로 사용).
• PAC-aware Load/Store 명령어:
  • ARMv8.3-A부터 도입된 Load/Store 명령어 확장으로, PAC가 적용된 포인터를 자동으로 인증하면서 로드하거나 저장할 수 있다.
  • 주로 pointer-authenticated 구조체나 함수 포인터 테이블 등에서 유용하게 사용된다.
  • 주요 명령어 예시는 다음과 같다:
    • LDRAA Rt, [Rn]: authenticated address를 로드하고, 인증이 성공하면 Rt에 값을 저장.
    • LDG Rt, [Rn]: tagged pointer를 인증하고 로드.
    • STG Rt, [Rn]: 인증된 pointer를 메모리에 저장.

  ; PAC된 포인터를 로드하는 예시
  ldraa x0, [x1]     ; x1이 가리키는 주소에서 PAC 인증된 값을 x0에 로드

  ; PAC된 포인터를 저장하는 예시
  paciza x2          ; x2에 대한 PAC 생성 (IA key 사용)
  stg x2, [x3]       ; PAC된 x2 포인터를 메모리에 저장

장점

• 하드웨어 기반 인증으로 기존 Software-only 방식보다 빠르고 강력한 포인터 보호를 제공
• 기존의 PAC-enabled 바이너리는 ARM TrustZone과 함께 사용할 경우 효과적인 격리 구조를 구현할 수 있음
• 기존 공격 방식(RSP, heap spraying 등)의 무력화를 유도하며, ROP gadget 연결 시도에 대해 실패 가능성을 높임

단점

• PAC는 컴파일 타임 혹은 링커 단계에서 적용되므로 기존 바이너리에는 적용이 불가능하며, 소스 레벨에서의 수정 혹은 설정이 요구됨
• PAC를 사용하기 위해서는 반드시 컴파일러 또는 어셈블러의 지원이 필요하다. 따라서 이는 Transparent한 방어 기법이 아니며, 코드 수준의 명시적인 구현 혹은 설정이 요구됨
• 성능 저하가 발생할 수 있으며, 특히 Performance-critical 컴포넌트에서는 눈에 띄는 오버헤드가 발생할 수 있음
  • 예: SPEC CPU2006의 sjeng 벤치마크 기준으로 PAC 도입 후 성능이 3배까지 저하된 사례가 보고됨
• NaCl이나 WebAssembly 기반의 Software Isolation에 비해 여전히 유연성에서 한계를 보일 수 있음
• 일부 연구 결과에 따르면, PAC 우회를 시도하는 취약점(exploit primitive)도 존재하므로 절대적인 방어 수단은 아님

참고

1. Limitations and Opportunities of Modern Hardware Isolation Mechanisms (Usenix ATC'24)
2. velog.io/@pensieveview/Pointer-authentication
3. ARM Architecture Reference Manual for ARMv8-A, Section on Pointer Authentication
4. PAC in Apple A12 and M1 Chips - Trail of Bits