Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Di shen pacsec_jp-final
Similar to Di shen pacsec_jp-final (20)
More from PacSecJP
More from PacSecJP (20)
Di shen pacsec_jp-final
- 1. 型破りな利用法をエクスプロイットする美学 - Androidカーネル内のUse-after-freeバグ Di Shen a.k.a. Retme (@returnsme) Keen Lab of Tencent
- 2. 自己紹介 • Di Shen a.k.a. Retme (@returnsme) • Keen Labのメンバー • 2014年よりAndroidカーネルの脆弱性ハンティングと攻撃を行っている • Androidの普遍的なroot取得攻撃を成功させることを目指している • トロフィー（実績）: • CVE-2016-6787 & CVE-2017-0403 (kernel/events/core.c) • CVE-2015-1805 (fs/pipe.c) の最初の実際に動く攻撃コード • CVE-2015-4421,4422 (Huawei TrustZone) • サムスン Galaxy S7 のKNOXバイパス (Black Hat USA 2017) • すべての一般的チップセットのワイヤレス拡張部分を攻撃 (Black Hat EU 2016) • さらに多くをアナウンスする予定 • https://github.com/retme7/My-Slides にて公開
- 3. アジェンダ • Androidのrootを奪う：現在の状況 • カーネルでのUse-After-Free攻撃の概要 • 一般的なアプローチ • その後：rootを奪う • 型破りなUse-After-Free攻撃 • perfシステムの実装 • CVE-2017-0403を活用 • CVE-2016-6787を活用 • 結論
- 4. Androidのrootを奪う：現在の状況 • 普遍的に攻撃可能な脆弱性は非常に少ない • 攻撃可能な側面： • Linuxの一般的なシステムコール • Binder, ION, AshmemなどのAndroidユニバーサル ドライバ
- 5. Androidのrootを奪う：現在の状況 • SELinux ポリシーの実行 • ほとんどのデバイスドライバにアクセスできない • 多くのシステムコールは信頼できないアプリケーションから アクセスできない • ソケットのioctlコマンドは部分的にしか実行できないように 制限されている
- 7. Androidのrootを奪う：これからの挑戦 • Privileged Access Never (PAN) • KASLR • ポインタ認証
- 8. カーネルにおけるUse-After-Free攻撃 • 簡単に悪用可能なUse-After-Freeバグには、通常、次のような 特徴がある： • 解放されたオブジェクトに関数ポインタがある • 攻撃者には解放されたオブジェクトに何かを追加するのに十分な時間 が有る
- 9. 一般的なUse-After-Free攻撃のアプローチ struct socket (freed) ops->ioctl(…) The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. struct socket (refilled) ops->ioctl(…) JOP ガジェット • 攻撃目標のオブジェクトを開放する • 解放されたオブジェクトにヒープ・スプレーもしくは ret2dir による不正な形式のデータを書き込む • 関数ポインタにカーネル内のROP/JOPガジェットを指し示 させる • 任意のカーネルコードを実行させるため、カーネルにこの関 数ポインタを参照させる ioctl(sockfd,…) kernel_sock_ioctl() JOP ガジェット
- 11. しかしながら… • カーネルのすべてのUse-After-Freeバグが理想的なものではない • 扱いにくい状況が多い… • 攻撃対象のオブジェクトには関数ポインタが無いかもしれない • Use-After-Freeを行った直後にカーネルがクラッシュするかもしれない • 攻撃者は書き込みを行ったオブジェクトを完全にコントロールできないか もしれない
- 12. 私が見つけた型破りなUse-After-Free • すべては sys_perf_event_open() にて見つかった • Perf システムに多くのバグがある • 昨年時点でアプリケーションによってアクセス可能 • しかし、今は、“perf_event_paranoid”という名の機能で制限がか かっている
- 13. 私が見つけた型破りなUse-After-Free • CVE-2017-0403 • Ever affected all devices shipped with 3.10 or earlier Linux kernel 3.10また はそれ以前のLinuxカーネルとともに出荷されたすべてのデバイスに影響 • KingRootの1400万人以上のユーザーがスマートフォンでroot権限を取得 • CVE-2016-6787 • Qualcommベースのすべてのデバイスに影響する (Qucalcomm enabled ハード ウェア perf エベントを有効化したQualcommのみ…) • サムスンKNOX 2.6をバイパスする一連の攻撃の一部
- 14. sys_perf_event_open() • perf_event を作成 • 入力：perf_event_attr • 必要なパフォーマンスイベントの種類を記述 • 入力： group_fd (optional) • 新しいperf_eventのグループリーダーを指定 • perf_eventのfdをユーザ空間に返す
- 15. perfシステムの重要なカーネルオブジェクト • perf_event • ユーザーが登録したパフォーマンスイベント • perf_event_context • 1つのプロセスで作成されたすべてのperfイベントのコンテナ • 各プロセスには、ソフトウェアイベント用とハードウェアイベント用 • の2つのコンテキストが有る • Perfグループとグループリーダー • 複数のイベントでグループを構成できる • 1つのイベントがリーダー perf_sw_context perf_hw_context task_struct event event event event_list event (group_leader) event (group_leader)
- 18. CVE-2016-6787 • move_groupは並行性の問題を無視 • Use-After-Freeは競合状態のために発生 • 攻撃者はmove_groupを同じグループリーダーで同時にトリガし、 • group_leader-> ctxのrefカウントは0に減らすことができる • ttask_struct-> perf_event_ctxp [perf_sw_context]が誤って解放され る オブジェクトが解放される
- 19. 解放された perf_event_context (PoC) ソフトウェア group_leader を作成 ハードウェア perf_event を作成 ハードウェア perf_event を作成 メインスレッド サブスレッド-1 サブスレッド-2 move_group, put_ctx() move_group, put_ctx() kfree_rcu(perf_event_context) ctx->refcount = 1 ctx->refcount = 2 ctx->refcount = 0
- 20. カーネルが直ちにクラッシュした • perf_event_contextを解放した 直後にカーネルがクラッシュ • スレッドスケジューラはこのオブ ジェクトを連続して参照する必要 がある • オブジェクトに書き込みを行う 時間が無い L
- 21. 解決策：解放後にスレッドをフリーズする • スレッドスケジューラを遠ざける • 攻撃者のスレッドの状態を実行中から割り込み (不)可能に切り替える • The thread will be frozen and kernel won’t crash as soon as perf_event_context freed • スレッドはフリーズされperf_event_contextが 解放された直後にもカーネルはクラッシュしない
- 22. ユーザ空間からスレッドをフリーズするには？ • Sleep() ? 動いていない • Use futex_wait_queue_me() 割り込み可能に切り替える freezable_schedule()
- 23. ソフトウェア group_leaderを 作成 ハードウェア perf_event を作成 ハードウェア perf_eventを作成 メインスレッド サブスレッド-1 サブスレッド-2 move_group, put_ctx() move_group, put_ctx() kfree_rcu(perf_event_context) futext_wait_queue_me() フェーズ 1 フェーズ 2 ‘ret2dir’トリックを使用してヒープをスプ レーし、不正な形式の perf_event_context {}を1024バイトごとに 書き込み futex_wake（）を使ってメイン スレッドを起動 フェーズ 4 schedule() finish_task_switch() perf_event_context_sched_in() ctx->pmu->pmu_disable() フェーズ 3
- 24. CVE-2016-6787の簡単な要約 • 容易に競合に「勝つ」ことができ、バグを引き起こせる • 解放されたオブジェクトに書き込むのが困難(時間が無い) • コードフローを簡単に制御できる (破損したオブジェクトには 関数ポインタがある) • スレッドをフリーズすることで、オブジェクトに書き込む時間 を増やす方法を提案
- 25. レビュー：perfイベント、グループとグループリーダーの関係 • グループリーダーは sibling_list を持っている • sibling_list はグループに属しているperfイベントのリスト perf_sw_context perf_hw_context task_struct event event event event_list event (group_leader) event (group_leader)
- 26. CVE-2017-0403 (PoC) • perfイベントを 'A'として作成 • 別のperfイベントを 'B'として作成し、グループリーダーとし て 'A'を指定 • グループリーダー ‘A’ を解放 • グループのsibling ‘B’ を解放 ß---- Use-after-free が
- 27. 根本的な原因 • グループリーダー‘A’ が解放された • カーネルはその sibling list を空にしない • 結果としてsibling’s event->group_entry にぶら下がっているポインタを残してしまう
- 28. 根本的な原因 • その後 sibling ‘B’ が解放される • list_del_event() • list_del_init(&event->group_entry); • 解放されたグループリーダーへのポインタを 上書き
- 29. • SLUB ポイズン情報 • 0xfffffc00fc2b1a0 が (group_leader+ 0x20) に上書きされる
- 30. 型破りなシナリオ • 私ができる唯一のことは、解放されたオブジェクトを次のように 上書きすること *(size_t*)(freed_object + 0x20) = (freed_object + 0x20)
- 31. Linuxのパイプサブシステム • readv() と writev() :パイプを通して複数のバッファを読み書き • ユーザバッファを記述するためにstruct iovec{iov_base,iov_len} の配列を使用 • 書き込み側で利用可能なコンテンツがない場合、readv() はカーネ ル内でブロックされることがある • そして、struct iovec {}の配列はカーネルのヒープに滞留するかも しれない
- 32. パイプシステムを攻撃 • readv() を呼び出す。 • rw_copy_check_uvector() はすべての iov_base がユーザ空間を指し ていることを確認。 • struct iovec{} の配列がヒープに加わった。パイプの書き込み終了から 何も来ないので、readv() はブロックする。 • もし iovec{} を上書きできるなら、 iov_baseカーネルアドレスに 変更。。。 iov_base iov_len iov_base iov_len iov_base iov_len ….. kernel_addr iov_len kernel_addr iov_len kernel_addr iov_len
- 33. パイプシステムを攻撃 • パイプのもう一方の端に何かを 書込む • pipe_iov_copy_to_user() は iov_base を再チェックしない • パイプに書かれたバッファは カーネルアドレス にコピーさ れる
- 34. ········ Use-After-Freeを引き起こす、 ２つの“A+0x20”の8バイト値を A+0x20のアドレスに書き込む ↓ 最初に解放されたオブジェクト, アドレスはA 解決策: Use-After-Freeを任意の読み書きに変換 ↓ 2番目に解放されたオブジェクト, アドレスは B = A + 0x400 iovec をヒープスプレーに使用 Freed Data Freed Data Freed Freed Data Freed Data ········· base len base len base base len base len ··················· base len A + 0x20 A+0x20 base ·········· base len base len バッファをパイプに書き込む、バッファは(A + 0x20) にコピーされる ········· base len KADDR 8 KADDR ·········· KADDR 8 KADDR 8 ········· バッファをパイプにもう一度コピーする，そうすると KADDR にコピーされる KADDR はどんなアドレス値をも取り得る、つまり、任意のカーネルメモリ上書きを達成 1 2 3 4 5
- 35. CVE-2017-0403の簡単な要約 • 攻撃者は解放されたオブジェクトのファイル記述子を失う • オブジェクトの関数ポインタに書き込んでコードを実行するこ とはできない • 解放されたオブジェクトのアドレス値は2回だけ解放されたオ ブジェクトに書き込むことができる • 新しい方法を提案した：パイプシステムへの攻撃
- 36. 結論 • ほとんどのUse-After-Freeバグは攻撃できないように見えるが、 他の方法があるかもしれない • 分からない？ しばらく置いておこう、しかし、見捨てないで… • カーネルコードに詳しくなろう, カーネルの独自機能が攻撃に 役立つかもしれない (例： CVE-2017-0403でのパイプ)