Pointer authentication code (PAC)

📝 Pointer authentication?

ARMv8.3 (AArch64) 에서 추가된 보안기법으로, Pointer를 사용하기 전 인증하고자 하는 목적으로 도입되었고, Pointer authentication code (PAC) 또는 Pointer authentication (PAuth) 라고도 불리고 있다.

Background

Function call/return 시에 생성되는 ret instruction을 이용한 Return oriented programming (ROP) 공격이 있다. 간략히 설명하자면 ret으로 연결되는 명령어를 반복 chaining 하면서 공격자가 원하는 대로 프로그래밍 하는 것인데, 프로그램의 call flow를 변경하는 것이 가능한 취약점이다. Jump oriented programming (JOP)도 같은 방식이고, 단지 br 등 instruction을 이용할 뿐이다.

PAC는 이를 방어하고자 pointer address의 무결성 (integrity)을 체크 해서, 아무데로나 call flow를 변경 할 수 없고, 프로그래머에 의해 의도되어 있는 곳으로만 return/branch 할 수 있게 강제하겠다는 기술이다.

In a nutshell

pointer address에 Keyed message authentication code (MAC)을 넣자!
그리고 Keyed MAC (인증코드)가 맞을 경우에만 pointer address를 사용하자!

그림으로 보자면, 모든 pointer 마다 아래와 같은 인증코드가 붙어있는 셈이다.

PAC는 64bit 주소체계에서 동작하는데, 64bit에서는 pointer 표현에 있어 사용되지 않는 top byte를 이용하고 있다. (MMU 구현에 따라 byte 수는 다름)

그림에서 열쇠모양이 인증코드를 생성하는 Key 역할을 하는데, Key는 pointer type과 privileged level에 따라 총 5가지 key가 사용된다.

• APIAKey, APIBKey → Instruction key
• APDAKey, APDBkey → Data key
• APGAKey → Generic key

A key는 user mode, B key는 kernel mode에서 사용된다.
그림에서 context/tweak은 Keyed MAC의 input으로 사용되며, output의 entropy를 준다. (간단히 말해서 PAC 값을 예측하기 어렵게 만든다는 뜻)

PAC를 만드는 시점에 사용되었던 key와 context/tweak을 이용하지 않으면 해당 pointer address를 사용할 수 없다. 공격자에 의해 call flow가 다른 지점에서 오게 되는 경우에는 key나 context/tweak이 맞지 않게 되므로 해당 return/branch를 허용하지 않게 된다는 것이 핵심.

📝 PAC instruction

PAC가 추가된 명령어 instruction은 아래와 같은 형태이다.
흔히 보이는 function prologue, body, epilogue에 pacisp, autiasp가 추가된 형태.
(<, >는 assembler에서는 없는 표현이지만, 가독성을 위해 추가하였다)

<function prologue>
  paciasp			; sign (lr=x30)
  stp fp, lr, [sp, #0]		; store lr
<function body>
<function epilogue>
  ldp fp, lr, [sp, #0]		; load lr
  autiasp			; authentication
  ret				; ret

크게 Sign/Authentication 동작으로 구분되며, Sign은 pointer에 PAC를 붙이는 과정, Authentication은 pointer 사용 시에 PAC를 검증하는 과정이다.

PAC* : pointer authentication code generation

PAC로 시작하는 계열의 instruction은, keyed MAC을 삽입하는 용도이다.
계산을 한 뒤 결과값은 target pointer address의 top byte에 위치시키게 된다.

PACIASP : Instruction key A로 lr의 PAC 계산 (context = sp, stack pointer)
PACIA x8, x9 : Instruction key A로 x8의 PAC 계산 (context = x9)
PACIAZ x8 : Instruction key A로 x8의 PAC 계산 (context = 0)

AUT*: pointer authentication code verification

AUT로 시작하는 계열의 instruction은, pointer address에 붙어있는 keyed MAC을 검증하는 용도이다. 검증이 맞을 시에는 PAC를 제거하고 pointer를 사용하게 되고, 검증이 틀릴 시에는 fault (SError)를 발생시킨다.

AUTIA x8, x9 : Instruction key A로 x8의 PAC 계산, valid pointer는 다시 x8에 위치

BLR, RET

그 외 추가되는 instruction은 AUT계열에 load나 return기능을 추가한 것.

BLRAA x8, x9 : authenticate-and-branch로 x8의 PAC 검증 후 branch
LDRA* : authentication-and-load
RETA* : authentication-and-return, LR의 PAC 검증 (context = sp) 후 ret

📝 PAC in your code

이론편을 그럭저럭 이해했으니, 각 실전 적용을 통해 실제 개발자가 어떻게 사용할 수 있는지 알아보았다

Kernel engineer

커널개발자라면, upstream에 올라와 있는 PAC 관련 config를 찾아볼 수 있다.

CONFIG_ARM64_PTR_AUTH

커널에서 exec 시점에 user application 마다 A key를 할당하게 되고, scheduling 될 때마다 key는 user context로 의 일부로 save/restore 해 주게 된다.
upstream patch: https://lore.kernel.org/lkml/20180503132031.25705-1-mark.rutland@arm.com/

Application engineer

개발자가 직접 pac, aut 코드를 assembly에 코딩할 수도 있겠지만,
보통은 직접 코딩보다는 컴파일러의 도움을 받아야 한다.

gcc 혹은 armclang에서는 아래와 같은 컴파일 옵션으로 PAC를 지원하고 있다.

-mbranch-protection=pac-ret+leaf+b-key

branch-protection이라는 라벨이 하나 추가되었으며, 여기서 사용될 수 있는 옵션은
standard: 모든 옵션 포함
pac-ret: PAC를 위한 default 옵션
leaf: function call stack의 leaf 노드까지 PAC를 적용하겠다는 옵션
b-key: b-key 사용 옵션

Android

android-ndk-r23-beta3 toolchain에서 PAC를 지원하고 있다.
android-ndk-r23-beta23/toolchains/llvm/prebuilt/linux-x86_64/bin/

$ aarch64-linux-android31-clang --version
Android (7211189, based on r416183) clang version 12.0.4

clang 12.0.x 이상 버전임이 확인되면, 아래 컴파일 명령을 통해 PAC를 적용할 수 있다.

$ aarch64-linux-android31-clang -o test test.c -mbranch-protection=pac-ret+leaf

iOS

Xcode에서 arm64e 빌드를 통해 PAC를 지원하고 있다.
가이드는 여기에 있고, ptrauth.h를 보시면 PAC key나 각종 PAC function들의 정의를 찾아볼 수 있다.

PAC-ed binary

위 컴파일러 옵션을 적용한 바이너리의 assembler를 뜯어보면 아래와 같이 되어 있다.

$ llvm-objdump
0000000000001770 <main>:
    1770: 3f 23 03 d5   hint    #25
    1774: ff 83 00 d1   sub     sp, sp, #32
    1778: fd 7b 01 a9   stp     x29, x30, [sp, #16]
    177c: fd 43 00 91   add     x29, sp, #16
...
    17a8: fd 7b 41 a9   ldp     x29, x30, [sp, #16]
    17ac: ff 83 00 91   add     sp, sp, #32
    17b0: bf 23 03 d5   hint    #29
    17b4: c0 03 5f d6   ret

hint #25 와 hint #29라는 명령어가 추가되어 있다!
해당 명령어는 ARM architecture reference 에서 나오는 opcode 통해서 해석할 수 있는데, hint #25는 pacisp에 해당된다. hint #29는 authisp가 된다.

일반적인 objdump를 사용하는 개발자라면, pac나 aut instruction이 보이지 않을텐데,
그 이유는 objdump에서 opcode 를 해석하는 방식에서 아직 PAC를 지원하지 않기 때문이며
강제로 binutil을 업데이트 하거나, llvm 재빌드를 한다면 볼 수 있다.

📝 Discussion

대부분의 ROP/JOP 취약점은 PAC를 적용하는 것만으로도 충분한 것 같다.
그 동안 ROP/JOP 방어기법으로 간단하게는 (=무력하게는) ASLR부터 code signing, shadow stack, CFI까지 많은 기법들이 소개되었는데 PAC는 하드웨어 적으로 성능문제를 최소화 해서 ROP/JOP를 상당히 많은 부분 방어하게 될 것으로 보인다.

다만, 늘 그렇듯 PAC를 다시 우회하는 취약점들이 나오고 있는데 다음 편에 이어서-.