===================================================================================================
iOS 11.2 では、kASLR スライドを特定するために利用できるカーネル情報漏洩が導入されました。この問題は、新しく追加された機能 __ARM_KERNEL_PROTECT__ が原因で、thread_get_state を使用してスレッドのレジスタ値を取得する際に、カーネル関数 Lel0_synchronous_vector_64_long のアドレスが誤ってレジスタ x18 に現れるようになったことに起因します。この問題は、iOS アプリのクラッシュログにカーネルポインタが現れ始めたことで発見されました。
iOS 11.2 で、Apple は arm64 上で __ARM_KERNEL_PROTECT__ と呼ばれる機能を導入しました。osfmk/arm64/proc_reg.h 内のコメントによると:
__ARM_KERNEL_PROTECT__ is a feature intended to guard against potential
architectural or microarchitectural vulnerabilities that could allow cores to
read/access EL1-only mappings while in EL0 mode. This is achieved by
removing as many mappings as possible when the core transitions to EL0 mode
from EL1 mode, and restoring those mappings when the core transitions to EL1
mode from EL0 mode.
つまり、EL1（カーネルモード）から EL0（ユーザーモード）に移行する際、できる限り多くのカーネルマッピングが削除されます。これにより、Spectre や Meltdown のようなマイクロアーキテクチャ上の脆弱性を悪用する際に、カーネルメモリマッピングに対する攻撃対象領域を制限できるはずです。
XNU バージョン 4570.20.62 と 4570.31.3 の差分を調べると、__ARM_KERNEL_PROTECT__ に関連して、ファイル osfmk/arm64/locore.s 内にレジスタ x18 への新しい参照が多数追加されていることがわかります。特に、システムコール（命令 svc #0）で呼び出される例外ベクタ Lel0_synchronous_vector_64 は、次のようになっています:
.text
.align 7
Lel0_synchronous_vector_64:
MAP_KERNEL
BRANCH_TO_KVA_VECTOR Lel0_synchronous_vector_64_long, 8
マクロ BRANCH_TO_KVA_VECTOR は次のように定義されています:
.macro BRANCH_TO_KVA_VECTOR
#if __ARM_KERNEL_PROTECT__
/*
* Find the kernelcache table for the exception vectors by accessing
* the per-CPU data.
*/
mrs x18, TPIDR_EL1
ldr x18, [x18, ACT_CPUDATAP]
ldr x18, [x18, CPU_EXC_VECTORS]
/*
* Get the handler for this exception and jump to it.
*/
ldr x18, [x18, #($1 << 3)]
br x18
#else
b $0
#endif /* __ARM_KERNEL_PROTECT__ */
.endmacro
このマクロは、関数へのポインタをレジスタ x18 にロードして、実際の例外ベクタ実装である Lel0_synchronous_vector_64_long への間接分岐を実行します。ただし、この x18 の破壊は、Lel0_synchronous_vector_64_long によって呼び出される関数 fleh_dispatch64 がユーザースペースのレジスタを保存する前に行われることに注意してください。つまり、ユーザーレジスタが保存される時点で、x18 はユーザースペース由来の元の値ではなく、実際には Lel0_synchronous_vector_64_long へのポインタになっているということです。
x18 は例外復帰時にクリアされるとはいえ、ユーザーレジスタ状態にカーネルポインタを格納することは問題です。なぜなら、thread_get_state を使用して、保存されたユーザーレジスタ状態（レジスタ x18 の値を含む）をユーザースペースにコピーできるからです。スレッドは、Lel0_synchronous_vector_64_long 関数のアドレスを取得するために、自分自身に対して thread_get_state を呼び出し、報告された x18 の値を確認するだけで済みます。これにより、取得した x18 の値から Lel0_synchronous_vector_64_long の静的アドレスを差し引くだけで、kASLR スライドを簡単に特定できます。
前述のとおり、悪用は簡単です。thread_get_state 関数を呼び出し、レジスタ x18 の値を確認し、そこからカーネル関数 Lel0_synchronous_vector_64_long の静的アドレスを差し引くだけです。
私は 2018 年 2 月 26 日に、iOS アプリのクラッシュログのレジスタ x18 にカーネルポインタが含まれていることに気づき、この問題を発見しました。簡単な確認により、デバイス上のすべてのクラッシュログのレジスタ x18 に同じ値が現れていることがわかり、深刻な情報漏洩が示唆されました。
次に、実験を通じてレジスタ x18 で実際に何が起きているのかを突き止めようとしました。空の iOS アプリにブレークポイントを設定し、lldb を使用してレジスタ x18 の値を読み取り、この漏洩がクラッシュするアプリに限定されないことを確認しました。次に、インラインアセンブリを使用して x18 の値を読み取ってみたところ、取得した値は、reg read x18 のようなコマンドを使用した場合にデバッガが表示する値と一致しませんでした。これは、漏洩が実際には thread_get_state にあり、CPU がユーザースペースで実行されている間、レジスタ x18 には実際にはカーネルポインタが含まれていないことを示唆していました。thread_get_state を使用して x18 の値を読み取る簡単な概念実証により、この関数がまさに漏洩の原因であることが確認されました。
私はこの問題を発見した当日である 2018 年 2 月 26 日に Apple に報告しました。
著者: Brandon Azad