カーネル空間からの セキュリティ セキュリティキャンプ2015 全国大会 @RKX1209

自己紹介 ● るくす(@RKX1209) ● 神戸大学 工学部 B3 ● seccamp'14 ソフトウェアセキュリティクラス卒業 ● seccamp'15 解析トラックチューター

話すこと ● Kernel Exploitによる権限昇格と対策 ● rootkitによる汚染と対策 ● Kernelセキュリティの動向 ring0で繰り広げられる仁義なき戦い

Kernel Exploitによる権限昇格と対策

Kernel exploit ● カーネル空間における不正なコード実行やメモリ破 壊などによるexploit ● 最高権限を持つカーネル空間への攻撃 => 成功した場合非常に危険 ● ただし制約が厳しい場合が多い => 高度なテクニックを要求される

Kernel exploit ● Local (kernel) exploit => ローカルにログインした状態での権限昇格 ex. BadIRET(CVE-2014-9322), Futex Bug(CVE-2014-3153) ● Remote (kernel) exploit => 外部からのpayload参入などによる権限昇格 ex. ROSE(CVE-2011-1493), SCTP(CVE-2009-0065)

BadIRET(CVE-2014-9322) ● カーネルのsystemcall処理中のダブルフォルト発 生がトリガー ● 不正なSSセグメントを設定した状態でiret ● iret前に余分なswapgsが実行されGSセグメントに 任意の値を設定できる脆弱性 => 現在殆ど資料が無いためもう少し詳しく...

BadIRET(CVE-2014-9322) ● ユーザー空間にてSS=(不正な値) GS=(任意の値) に設定する ● swapgsによって現在のGSにユーザー空間で設定 したGS(任意の値)が設定される ● この状態でgeneral_protectionに飛ぶ [1] bad_iret: pushq $0 SWAPGS jmp general_protection [2] do_general_protection (GS = arbitrary value) …..

BadIRET(CVE-2014-9322) ● general_protection内でcurrent→tsk→threadに0 を設定する処理がある ● currentは%gs:0xc780とアクセスされるためGSを 書き換えると任意のアドレスに0を設定する事がで きる ● どこを書き換えるか？ => カーネル内で関数ポインタをもつデータ構造 ここではproc_root->inode_operationsにする

BadIRET(CVE-2014-9322) ● 何に書き換える？ => カーネル内のROP gadgetのアドレス ● Stack pivotを行い シェルコードを実行 ● カーネルモードで動作 しているためシェルコード 内でroot昇格可能

kernel exploit対策 ● Intel SMEP => カーネルモード時はユーザー空間のコードを実行出 来ないようにする 第3世代（Ivy Bridge）以降のCPUが搭載 ● Intel SMAP => カーネルモード時はユーザー空間のデータにアクセス 出来ないようにする BadIRETはSMEPをバイパス可能 しかしユーザー空間のデータFAKE_IOPSなどを利用するため SMAPはバイパスできない

rootkitによる汚染と対策

rootkit ● システムに侵入後、使用されるソフトウェアツールの セット ● 痕跡消去,backdoor作成など ● カーネルレベルの物とユーザーレベルの物がある => 今回は前者について

LKM rootkit ● LKM(Loadable Kernel Module)を利用したrootkit ● システムコールの書き換えにより自身の隠蔽などを 行う ● Knark, Adore, Rkitなど多くの種類が存在 ● カーネルレベルから偽装されるため解析が非常に 困難

Anti rootkit ● Kernel Module Signing => 署名されたモジュールしかロードさせない ● NICKLE => memory shadow-ingを用いてメモリ検証 VMMとして実装されている ● RG(Rootkit Guard) => Teh Jia Yew(2013)のペーパーより

RG(Rootkit Guard) ● Rootkitの検知を行うRIDS, 防止を行うRIPSにより 構成 ● Linux IMAによりあらかじめ正しいファイルやモジュー ルのデータベースを作成(SHA1) ● ユーザーの定義したクリティカルなファイルは暗号化 されたパーティションに格納(TPMを利用) ● ファイル保護にはSELinuxを用いる ● ブート時の汚染を防ぐためtrusted GRUBを利用する

RG(Rootkit Guard)

Kernelセキュリティの動向

Kernel security ● PaXなどのセキュリティパッチ ● “Return-less” kernel ● LLVM Linux ● Trinity(fuzzing) ● Symbolic実行

PaX ● grsecurityによる、最小特権保護を実装したLinux カーネル向けセキュリティパッチ ● カーネルスタックアドレスのrandomize ● SMAPを模したUDEREF ● スタックの再利用防止STACKLEAK => 多くのセキュリティ機構をカーネルに加える

Return-less kernel ● カーネルからret命令を排除する ● EuroSys10にて公開 ● Kernel exploitやrootkitにおけるカーネル内のROP gadget利用を防止する ● LLVMを用いて実装されている

LLVM Linux ● Linux kernelをclang(LLVM)でコンパイルするプロ ジェクト ● Linux kernelのコードにはgcc拡張が多いためメイ ンラインへの統合は難しい ● LLVM static analyzerを用いたkernelコードの検証 にも応用可能 => “Applying Clang Static Analyzer to Linux Kernel” LinuxCon(2012)

Trinity(kernel fuzzing) ● カーネルのfuzzing用ツール ● hardeningというよりはdetection ● 様々なパラメータによるシステムコールの呼び出し を行う ● 開発者が疲弊してるらしく存続するかは不明....

Symbolic実行 ● ソフトウェアテスト手法の一つ ● どの入力値でどの実行経路を通るか特定する ● 計算量爆発が起こるため多くの場合は動的symbolic実行 を行う ● LLVM bitcodeを用いたKLEEなどがある => カーネルドライバなどの開発においてこれらを用いるの は現実的か？ => 現在の開発体制ではテスト方式は決まっていない => 開発サイクルとのトレードオフ

おわりに ● カーネルに関わるセキュリティ技術に関して3つの 観点から紹介しました ● ユーザー空間とは比較にならないほどの危険が潜 む ● 高度なテクニックやシステムに関する深い知識が要 求される ユーザー空間では物足りないと思ったら カーネル空間にダイブしてみましょう

reference ● Rootkit Guard (RG) - An Architecture for Rootkit Resistant File-System Implementation Based on TPM [http://psasir.upm.edu.my/30621/] ● Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms [https://www.usenix.org/legacy/event/sec09/tech/full_papers/hund.pdf] ● ももいろテクノロジー [http://inaz2.hatenablog.com/] ● 『A Guide to Kernel Exploitation: Attacking the Core』(Massimiliano Oldani pub. Syngress 2010) ● 一生あとで読んでろ [http://ntddk.github.io/] ● Writing kernel exploits [http://kmcallister.github.io/talks/security/2012-kernel-exploits/talk.pdf] ● Anatomy of a Remote Kernel Exploit [http://vulnfactory.org/research/h2hc-remote.pdf] ● Applying Clang Static Analyzer to Linux Kernel(LinuxCon 2012) [https://events.linuxfoundation.org/images/stories/pdf/lcjp2012_matsumotoh.pdf] ● Defeating Return-Oriented Rootkits with "Return-less"Kernels [http://eurosys2010.sigops-france.fr/slides/eurosys2010_session6_talk15.pdf]