osセキュリティチュートリアル
TRANSCRIPT
チュートリアル 2014/Jan/8/ /OS周りのセキュリティ対策
須崎有康須崎有康
Quizセキ リテ 技術と実装名を関係づけよセキュリティ技術と実装名を関係づけよ。
注:1対1対応でないよ。
• DEP • SELinuxT i i• ASLR
• Code Signing
• Tripwire• Exec ShieldCode Signing
• Sandbox • W^XT S S• Access Control
• Encrypt Storage
• TrouSerS• BitLockerEncrypt Storage
• Integrity Check • Jail
• Trusted Computing • PAX
Quizセキ リテ 技術と実装名を関係づけよセキュリティ技術と実装名を関係づけよ。
注:1対1対応でないよ。
• DEP • SELinuxT i i• ASLR
• Code Signing
• Tripwire• Exec ShieldCode Signing
• Sandbox • W^XT S S• Access Control
• Encrypt Storage
• TrouSerS• BitLockerEncrypt Storage
• Integrity Check • Jail
• Trusted Computing • PAX
OSのセキュリティ例 Wi d 8の多層防衛例:Windows8の多層防衛
システム境界の対策
検知と実行制御
脆弱性対策 権限管理リソース
保護・管理OS保護
EFS System領
域W
SmartScreen
DEP
初期
設
Secure b
UAC
整合
性レベ
BitLock
m域W
indows D
e
AppLock
保護されたビュー
HE
ASLRP
設定
による対
脆弱
性
boot
ベル
kerRM
Program領
域
efender
ker
No Autorun
WindowsHeap
Protection
対策
MS
m
WindowsFirewall アプリケーション
「マイクロソフトにおけるサイバー攻撃への対処」よりhttp://www.soumu.go.jp/main_content/000264302.pdf
バイナリに対する攻撃・防御の歴史バイナリに対する攻撃・防御の歴史
E ec te Code R T Lib A k Reuse to Unsafe
攻撃技術総当たり攻撃やアドレス漏えいを利用しExecute Code
on the Stackスタックに攻撃コード
を置き、実行
Rturn‐To‐Libc Attack既に存在する実行コードを使うだけなので、DEP防ぐことができない
Reuse to UnsafeCode Gadgets(Return Oriented
Programming: ROP)
レス漏えいを利用してASLRを回避できる
1980 1990 2000 2010
Stack GuardCompiler
既存防御技術 Type Checking GuardCompiler
OS
Address Space Layout
R d i ti
Data Execution P ti
Moving Target Defense&
Instruction Set
Checking
OS
H d
Randomization(ASLR)
Prevention (DEP)
Randomization
次の防御技術生命の防衛技術を模したセキHardware AMD NX bit
Intel DX bit
生命の防衛技術を模したセキュリティ(多様性, 自己修復,免疫) (産総研の萌芽研究 「生命型セキュリティ」 H25- )
DEP: Data Execution Preventionデータ実行防止データ実行防止
• スタックやヒープ領域等にコードを置き、実行する攻撃を防ぐ。
• スタックやヒープは“通常”はコードが置かれることがないので、このメモリ領域を実行禁止にする。
が• 物理メモリ自体には属性がない。メモリの属性は仮想メモリで使うページテーブルにあるが、Read/Write, Supervisor/User, Present bit, Dirty bitなどで実行の禁止が無かった (今はある 後述)Dirty bitなどで実行の禁止が無かった。(今はある。後述)
DEPの実装DEPの実装
ソフトウ アでの実装• ソフトウェアでの実装
– エミュレーションでの実装(PAX)– x86のコードセグメント境界を利用 (ExecShiled)
• ハードウェアを使った実装• ハ ドウェアを使った実装
– SPARC, Alpha, PowerPCでは古くから対応。Intel系では2000年以降は2000年以降。
• Intel Itanium Merced 2001以降
• Intel DX (eXecute Disable)bit:Pentium4 Prescott 2004/1以降
ADM NX (N X t ) bit AMD64 2003/9以降• ADM NX (No eXecute) bit : AMD64 2003/9以降
DEPの実装例• OpenBSD
– W^X (2003年5月1日)読み方"Write XOR Execute"W X (2003年5月1日) 読み方 Write XOR Execute• エミュレーションor NX bitを使う
• Linux• Linux– “PAX” (2000年10月1日)
• エミュレーションor NX bitを使う
– “Exec Shield” by Ingo Molnar(2003年5月2日)• x86のコードセグメント境界を利用
• NX bitを使うカーネルパッチもあり
• WindowsWi d XP S i P k 2とWi d S 2003– Windows XP Service Pack 2とWindows Server 2003 Service Pack 1 (2004年8月6日)
DEPの問題問題
• Self‐modifying code(自己書き換えコード)に対応できない
– Code obfuscation(難読化)では必要なものがある
– GCCで使われてる「トランポリン」(動的に生成したコードを経由する)は使えない。
– 自己書き換えによる最適化
• cpuid命令の結果からコードを書き換える– http://mkosaki.blog46.fc2.com/blog‐entry‐104.html 「alternative マクロと自己修正コ ド」よりクロと自己修正コード」より
– 元を正せばマルチプロセッサ同期命令などという基本的な命令をP6, Pentium4などという超最近に追加するIntelが悪いのが、素直にコン
パイルオプションなぞにしてしまったら、ディストリビュータはきっとPentium4をOFFにしたGenericカーネルを配布しだして遅くなるし条件
分岐命令なんぞいれた日にゃあ目も当てられない速度になるのは分岐命令なんぞいれた日にゃあ目も当てられない速度になるのは請け合い。ってことで、かなり強引な手法がとられている。
DEPの回避方法M D l iMemory Dual mapping
• Matt “skape” Miller, Using dual‐mappings to evade automated unpackers, 2008より。
• 2つの仮想メモリページを1つ物理メモリページに割り当てる
Vi t l Physical
– Executable mapping• コードが実行される。Debugger
DEP, Debuggerの監視対象はコードのみ Virtual Physical
はここのみ監視
– Editable mappingとして働き ドを改 C d
コ ドのみ
• Packerとして働き、コードを改変(Self‐modification)する
• DEP(Data Execution Prevention)
CodeExecutable
DEP(Data Execution Prevention)を回避して、コード改変
Dataデータとして実Editable データとして実行コードを書き換え
DEPを回避する攻撃ROP: Return Oriented Programming
プログラムを書き換
攻撃 ドは タ ク上の置 えてやろう
スタックメモリが無防備だぞ!
対策技術• 攻撃コードはスタック上の置かれて実行されてきたが、スタック上でコード実行できな
スタックをオーバフローさせて攻撃コードを書き込む スタック上ではプログラ
ムを実行できなくするNX (no execute)モード
タック上でコ ド実行できないような仕組み(DEP:DataExecution Prevention)が開発
Return oriented programming
NX (no execute)モード
された。
• これを回避する攻撃として既存 ドを組み合わせ 攻撃コード
スタック上のリターンアドレスを変えて、正常コードの断片を呼び出
す順番を変える
存のコードを組み合わせて攻撃コードを作成するROP: Return Oriented
readwrite
comp
copy
正常コード
Return Oriented Programmingが出てきた。
write copy
Return Oriented ProgrammingReturn Oriented Programming• Bufferover Flow等でスタックを破壊する。• メモリ上にあるRET命令の直前のコードを集めてプログラムを作る。スタッ
ク上ではRETの直前のアドレスに移るようにスタックフレームを改ざんする。
ROPで作られたスタック
リターンアドレス
XXXX MOVE A,BRET
メモリ上のコード ROPで作られた攻撃コード
リターンアドレス
XXXX
リターンアドレス
YYYYY
RET…ADD A,CMUL A B
MOVE A,BADD A,CMUL A Bリタ ンアドレス
YYYYY
リターンアドレス ZZZZ
MUL A,BRET…MOVE B C
MUL A,BMOVE B,C左を実行する
と右の攻撃リタ ンアドレス
ZZZZ ZZZZ MOVE B,CRET
コードを実行するのと同じ
スタックを攻撃スタックフレームのリターンアドレスを積みなす
ASLR• ROP自体はプログラムの起動時にコードをランダムに配置するASLR: Address Space Layout Randomization により減少された。
メモリ上のコード
XXXX‐8192 MOVE A,BRET…
スタック
リターンアドレス
YYYYY‐8192
…ADD A,CMUL A,BRET
リターンアドレス
XXXX
リターンアドレス
ZZZZ‐8192
RET…MOVE B,CRET
リタ ンアドレス
YYYYY
リターンアドレス RET
ASLRではメモリロードにアドレスをランダムに配置(ずらす)することで
リタ ンアドレス
ZZZZ
ランダムに配置(ずらす)することでROPを意味のないものにする。スタックを攻撃
スタックフレームのリターンアドレスを積みなす
ASLRのイメージS のイメ ジ• 仮想メモリ内の位置を移動(全体がランダムにならない)
また アドレスビ トの変えられる位置は多くない– また、アドレスビットの変えられる位置は多くない
• 下位12bit (4KB)はページで固定。
• 上位はカーネル空間、ユーザ空間で切り分けている。– Linux 32bitの場合、上位1GBがカーネル、下位3GBがユーザ。
カーネル 1回目実行 2回目実行 3回目実行
0xFFFFFFFF
0xC0000000
ユ ザ
コード
プ
コード
ヒープ
コード
ヒープ開始アドレスが変わユーザ
スタック
ヒープ
スタック
ヒ プ
スタック
が変わるのみ
32ビットASLRでは数ビットを変えるのみでエントロピーを確保できない。
0x00000000
ASLR のランダムさの程度• 「Windows Server 2012 R2 マイグレーションガイド」より。http://download.microsoft.com/download/0/7/B/07BE7A3C‐07B9‐4173‐B251‐6865ADA98E5D/WS2012R2_MigrationGuide_v2.0.docx
メモリ領域Windows 7 および 2008 R2 Windows 8 および Windows Server 2012 以降
• 例:8 ビットの場合、256 通りの中からベースアドレスが決まる
メモリ領域
32 ビットプロセス 64 ビット プロセス 32 ビット プロセス 64 ビット プロセス64 ビット プロセス
(HE 有効)
ボトム アップの割り当プ
0 (ランダム化 0 (ランダム化 8 8 24て (オプト イン) なし) なし) 8 8 24
スタック 14 14 17 17 33ヒープ 5 5 8 8 24
トップ ダウンの割り当て (オプト イン)
0 (ランダム化なし)
0 (ランダム化なし) 8 17 17
PEB、TEB 4 4 8 17 17EXE イメージ 8 8 8 17 * 17 *
DLL イメージ 8 8 8 19 * 19 *
非 ASLR DLL イメー 0 (ランダム化 0 (ランダム化非 ASLR DLL イメジ (オプト イン)
0 (ランダム化なし)
0 (ランダム化なし) 8 8 24
表: Windows 7 と Windows 8 の ASLR の⽐較、数字はエントロピーのビット数* ベース アドレス 4 GB 未満の 64 ビット EXE には 8 ビット、64 ビット DLL には 14 ビットのエントロピーが適⽤される
ASLRの課題
• バイナリ自体をPIC(Position Independent Code)にする必要あり。
• 絶対アドレスを指定されている古いバイナリはASLRを活用できない。
• ASLRはロード時のみに配置を一回変えるので、一度アASLRはロ ド時のみに配置を 回変えるので、 度アドレスが漏えいしたら意味がない。
– ApacheなどForkのみでプロセスを多く派生するものは危険。ApacheなどForkのみでプロセスを多く派生するものは危険。• Execすればよいが、多くは行っていない。
– Re‐Randomization の必要性Re Randomi ationの必要性• タネンバウム研のUSENIX‐SEC12論文
– Enhanced Operating System Security Through Efficient and Fine‐grained Add S R d i tiAddress Space Randomization
Windowsのセキュリティ向上Windowsのセキュリティ向上
XP SP0 XP XP2 Vista, 7 Win 8
DEP(software) × ○ ○ ○
DEP(h d ) × ○ ○ ○DEP(hardware) × ○ ○ ○
ASLR(stack) × × ○ ◎
ASLR(module) × × ○ ◎ASLR(module) × × ○ ◎
ASLR(heap) × × × ○
カーネル保護 × × △ ○(ASLR)
FFRI 「 Windows 8 – 脆弱性緩和機能の強化 」よりhttps://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC0QFjAA&url=http%3A%2F%2Fwww.ffri.jp%2Fassets%2Ffiles%2Fmonthly_research%2FMR201209_Windows8_Exploit_Mitigation.pdf&ei=t2DLUuPoL4SlkwXHsIHgCg&usg=AFQjCNGIBa1L4fHZrw7qHQhVRQWTYf2aTA&sig2=btFLcMsnvqnEd5DyzKNMCw&bvm=bv.58187178,d.dGI
ASLRの次Moving Target DefenseMoving Target Defense
• Moving Target Defense 存 じMoving Target Defense– 現在の攻撃は全てのマシンで同じバイナリが使われているため 既存
既存のシステムは同じバイナリを使うので攻撃対象になりやすい。
イナリが使われているため、既存コード再利用攻撃を受けやすい。
– 個々のマシンで異なるバイナリにす バイナリ自体がシステ個々のマシンで異なるバイナリにすることで、攻撃を難しくする。(多様性)
バイナリ自体がシステム毎に変化することで攻撃を回避する。
• Instruction Set RandomizationInstruction Set Randomization• 実行毎にバイナリコードを変える。
• この数年で論文が出てきている コードもある• この数年で論文が出てきている。コ ドもある。
• Minestone [ACSAC’10] http://nsl.cs.columbia.edu/projects/minestrone/isr/• Binary Stirring[CCS’12,テキサス大ダラス]y g[ , ]• ORP [IEEE SSP12,コロンビア] http://nsl.cs.columbia.edu/projects/orp/
ISR: Instruction Set Randomization• 既存のバイナリコードを等価な命令で置きかえることでROPによるコード再利用を防ぐ。
実行ディスク メモリ
今までの方式div b / 2mul a x 2
でROPによるコ ド再利用を防ぐ。
(ローダ) アドレスコード領域
div b / 2mul a x 2mul a x 2xor a, aret
div b / 2mul a x 2mul a x 2xor a, aret
同じ命令が実行される
mul a x 2mul a x 2xor a, aret
攻撃者が同じコ ドを入手retret
実行
メモリ内容が全く違う
ディスクISR
コードを入手、解析、攻撃
div b / 2l
成功
実行コード変換
メモリ
アドレスコード領域
shift l aadd a+aAdd a+a
0等価な命令に置き
ディスク
div b / 2mul a x 2mul a x 2xor a a
mul a x 2mul a x 2xor a, aret
攻撃者が同じmv 0, ajump
等価な命令に置き換えられる
xor a, aret
コードを入手、解析、攻撃失敗
• 問題点:セマンティックが変わらない場合 ROPに効• 問題点:セマンティックが変わらない場合、ROPに効果が無いのでは?評価が重要。
外部の動向外部の動向Moving Target Defense
• NISC「米国における情報セキュリティ研究開発戦略の動向について」2012/06より
まとめまとめ
キ 強 プ 基本• OS内のセキュリティ強化のアプローチは基本的に2つ
–それしか使えないか
DEP S db A C t l C d i i• DEP, Sandbox, Access Control, Code signing–でたらめにするか
• ASLR, ISR (Instruction Set Randomization)