osセキュリティチュートリアル

21
チュートリアル 2014/ Jan/8 OS周りのセキュリティ対策 須崎有康 須崎有康

Upload: kuniyasu-suzaki

Post on 28-May-2015

6.222 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: OSセキュリティチュートリアル

チュートリアル 2014/Jan/8/ /OS周りのセキュリティ対策

須崎有康須崎有康

Page 2: 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

Page 3: 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

Page 4: OSセキュリティチュートリアル

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

Page 5: OSセキュリティチュートリアル

バイナリに対する攻撃・防御の歴史バイナリに対する攻撃・防御の歴史

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- )

Page 6: OSセキュリティチュートリアル

DEP: Data Execution Preventionデータ実行防止データ実行防止

• スタックやヒープ領域等にコードを置き、実行する攻撃を防ぐ。

• スタックやヒープは“通常”はコードが置かれることがないので、このメモリ領域を実行禁止にする。

が• 物理メモリ自体には属性がない。メモリの属性は仮想メモリで使うページテーブルにあるが、Read/Write, Supervisor/User, Present bit, Dirty bitなどで実行の禁止が無かった (今はある 後述)Dirty bitなどで実行の禁止が無かった。(今はある。後述)

Page 7: OSセキュリティチュートリアル

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以降

Page 8: OSセキュリティチュートリアル

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日)

Page 9: OSセキュリティチュートリアル

DEPの問題問題

• Self‐modifying code(自己書き換えコード)に対応できない

– Code  obfuscation(難読化)では必要なものがある

– GCCで使われてる「トランポリン」(動的に生成したコードを経由する)は使えない。

– 自己書き換えによる最適化

• cpuid命令の結果からコードを書き換える– http://mkosaki.blog46.fc2.com/blog‐entry‐104.html 「alternative マクロと自己修正コ ド」よりクロと自己修正コード」より

– 元を正せばマルチプロセッサ同期命令などという基本的な命令をP6, Pentium4などという超最近に追加するIntelが悪いのが、素直にコン

パイルオプションなぞにしてしまったら、ディストリビュータはきっとPentium4をOFFにしたGenericカーネルを配布しだして遅くなるし条件

分岐命令なんぞいれた日にゃあ目も当てられない速度になるのは分岐命令なんぞいれた日にゃあ目も当てられない速度になるのは請け合い。ってことで、かなり強引な手法がとられている。

Page 10: OSセキュリティチュートリアル

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 データとして実行コードを書き換え

Page 11: OSセキュリティチュートリアル

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

Page 12: OSセキュリティチュートリアル

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

コードを実行するのと同じ

スタックを攻撃スタックフレームのリターンアドレスを積みなす

Page 13: OSセキュリティチュートリアル

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を意味のないものにする。スタックを攻撃

スタックフレームのリターンアドレスを積みなす

Page 14: OSセキュリティチュートリアル

ASLRのイメージS のイメ ジ• 仮想メモリ内の位置を移動(全体がランダムにならない)

また アドレスビ トの変えられる位置は多くない– また、アドレスビットの変えられる位置は多くない

• 下位12bit (4KB)はページで固定。

• 上位はカーネル空間、ユーザ空間で切り分けている。– Linux 32bitの場合、上位1GBがカーネル、下位3GBがユーザ。

カーネル 1回目実行 2回目実行 3回目実行

0xFFFFFFFF

0xC0000000

ユ ザ

コード

コード

ヒープ

コード

ヒープ開始アドレスが変わユーザ

スタック

ヒープ

スタック

ヒ プ

スタック

が変わるのみ

32ビットASLRでは数ビットを変えるのみでエントロピーを確保できない。

0x00000000

Page 15: OSセキュリティチュートリアル

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 ビットのエントロピーが適⽤される

Page 16: OSセキュリティチュートリアル

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

Page 17: OSセキュリティチュートリアル

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

Page 18: OSセキュリティチュートリアル

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/

Page 19: OSセキュリティチュートリアル

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に効果が無いのでは?評価が重要。

Page 20: OSセキュリティチュートリアル

外部の動向外部の動向Moving Target Defense

• NISC「米国における情報セキュリティ研究開発戦略の動向について」2012/06より

Page 21: OSセキュリティチュートリアル

まとめまとめ

キ 強 プ 基本• OS内のセキュリティ強化のアプローチは基本的に2つ

–それしか使えないか

DEP S db A C t l C d i i• DEP, Sandbox, Access Control, Code signing–でたらめにするか

• ASLR, ISR (Instruction Set Randomization)