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

2. Quiz
セキュリティ技術と実装名を関係づけよ。
セキ リテ 技術と実装名を関係づけよ
注：１対１対応でないよ。
•
•
•
•
•
•
•
•
DEP
ASLR
Code Signing
Code Signing
Sandbox
Access Control
Encrypt Storage
Encrypt Storage
Integrity Check
Trusted Computing
•
•
•
•
•
•
•
•
SELinux
Tripwire
Ti i
Exec Shield
W^X
TrouSerS
T S S
BitLocker
Jail
PAX

3. Quiz
セキュリティ技術と実装名を関係づけよ。
セキ リテ 技術と実装名を関係づけよ
注：１対１対応でないよ。
•
•
•
•
•
•
•
•
DEP
ASLR
Code Signing
Code Signing
Sandbox
Access Control
Encrypt Storage
Encrypt Storage
Integrity Check
Trusted Computing
•
•
•
•
•
•
•
•
SELinux
Tripwire
Ti i
Exec Shield
W^X
TrouSerS
T S S
BitLocker
Jail
PAX

4. OSのセキュリティ
例：Windows8の多層防衛
例 Wi d
8の多層防衛
システム境界
の対策
検知と
実行制御
脆弱性対策
リソース
保護・管理
RM
MS
Program
m
領域
Secure b
boot
BitLock
ker
「マイクロソフトにおけるサイバー攻撃への対処」より
http://www.soumu.go.jp/main_content/000264302.pdf
OS保護
System
m
領域
域
EFS
UAC
Heap
Protection
P
アプリケーション
整合性レベ
ベル
HE
ASLR
脆弱性
初期設
設定による対
対策
Windows
Firewall
AppLock
ker
No Autorun
Windows De
W
efender
保護された
ビュー
DEP
Smart
Screen
権限管理

5. バイナリに対する攻撃・防御の歴史
攻撃技術
Execute Code
E ec te Code
on the Stack
Rturn‐To‐Libc A
R
T Lib Attack
k
既に存在する実行コードを
使うだけなので、DEP防ぐこ
とができない
スタックに攻撃コード
を置き、実行
1980
既存防御技術
Compiler
OS
Reuse to Unsafe
Reuse to Unsafe
Code Gadgets
1990
Type
Checking
総当たり攻撃やアド
レス漏えいを利用し
てASLRを回避できる
(Return Oriented
Programming: ROP)
2000
2010
Stack
Guard
Data
Execution
Prevention
P
ti
(DEP)
Address Space
Layout
Randomization
R d i ti
(ASLR)
Moving Target Defense
&
Instruction Set
Randomization
次の防御技術
Hardware
H d
AMD NX bit
Intel DX bit
生命の防衛技術を模したセキュ
生命の防衛技術を模したセキ
リティ(多様性, 自己修復,免疫)
(産総研の萌芽研究 「生命型セ
キュリティ」 H25- )

6. DEP: Data Execution Prevention
データ実行防止
• スタックやヒープ領域等にコードを置き、実行する攻撃を防ぐ。
• スタックやヒープは“通常”はコードが置かれることがないので、この
メモリ領域を実行禁止にする。
• 物理メモリ自体には属性がない。メモリの属性は仮想メモリで使う
が
ページテーブルにあるが、Read/Write, Supervisor/User, Present bit,
Dirty bit などで実行の禁止が無かった。(今はある。後述)
Dirty bit などで実行の禁止が無かった (今はある 後述)

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

8. DEPの実装例
• OpenBSD
– W^X (2003年5月1日) 読み方"Write XOR Execute"
W X (2003年5月1日) 読み方 Write XOR Execute
• エミュレーションor NX bitを使う
• Linux
– “PAX” (2000年10月1日)
• エミュレーションor NX bitを使う
– “Exec Shield” by Ingo Molnar(2003年5月2日)
• x86のコードセグメント境界を利用
• NX bitを使うカーネルパッチもあり
• Windows
– Wi d
Windows XP Service Pack 2とWindows Server 2003
XP S i P k 2とWi d
S
2003
Service Pack 1 (2004年8月6日)

9. DEPの問題
問題
• Self‐modifying code(自己書き換えコード)に対応できない
– Code obfuscation(難読化)では必要なものがある
– GCCで使われてる「トランポリン」（動的に生成したコードを経由
する）は使えない。
– 自己書き換えによる最適化
• cpuid命令の結果からコードを書き換える
– http://mkosaki.blog46.fc2.com/blog‐entry‐104.html 「alternative マ
クロと自己修正コード」より
クロと自己修正コ ド」より
– 元を正せばマルチプロセッサ同期命令などという基本的な命令をP6,
Pentium4などという超最近に追加するIntelが悪いのが、素直にコン
パイルオプションなぞにしてしまったら、ディストリビュータはきっと
Pentium4をOFFにしたGenericカーネルを配布しだして遅くなるし条件
分岐命令なんぞいれた日にゃあ目も当てられない速度になるのは
請け合い。ってことで、かなり強引な手法がとられている。

10. DEPの回避方法
Memory Dual mapping
M
D l
i
• Matt “skape” Miller, Using dual‐mappings to evade automated
unpackers, 2008 より。
• 2つの仮想メモリページを1つ物理メモリページに割り当てる
– Executable mapping
• コードが実行される。Debugger
はここのみ監視
DEP, Debugger
の監視対象は
コ ドのみ
コードのみ
Virtual
Vi t l
Physical
– Editable mapping
• Packerとして働き、コードを改
として働き
ドを改
変(Self‐modification)する
Code
C d
Executable
• DEP(Data Execution Prevention)
DEP(Data Execution Prevention)
を回避して、コード改変
Data
Editable
データとして実
行コードを書き
換え

11. DEPを回避する攻撃
ROP: Return Oriented Programming
• 攻撃
攻撃コードはスタック上の置
ドは タ ク上の置
かれて実行されてきたが、ス
タック上でコ ド実行できな
タック上でコード実行できな
いような仕組み(DEP:Data
Execution Prevention)が開発
された。
• これを回避する攻撃として既
存のコードを組み合わせて
存
ドを組み合わせ
攻撃コードを作成するROP:
Return Oriented
Return Oriented
Programmingが出てきた。
プログラムを書き換
えてやろう
対策技術
スタックメモリが無防
備だぞ！
スタックをオーバフローさ
せて攻撃コードを書き込
む
スタック上ではプログラ
ムを実行できなくする
NX (no execute)モード
Return oriented programming
攻撃コード
スタック上のリターンアドレスを変
えて、正常コードの断片を呼び出
す順番を変える
正常コード
comp
read
write
copy

12. Return Oriented Programming
Return Oriented Programming
•
•
Bufferover Flow等でスタックを破壊する。
メモリ上にあるRET命令の直前のコードを集めてプログラムを作る。スタッ
ク上ではRETの直前のアドレスに移るようにスタックフレームを改ざんする。
スタック
リターンアドレス
XXXX
リタ ンアドレス
リターンアドレス
YYYYY
リタ ンアドレス
リターンアドレス
ZZZZ
スタックを攻撃
スタックフレームのリター
ンアドレスを積みなす
メモリ上のコード
XXXX MOVE A,B
RET
…
YYYYY ADD A,C
MUL A,B
MUL A B
RET
…
ZZZZ
MOVE B,C
MOVE B C
RET
ROPで作られた
攻撃コード
左を実行する
と右の攻撃
コードを実行
するのと同じ
MOVE A,B
ADD A,C
MUL A,B
MUL A B
MOVE B,C

13. ASLR
• ROP自体はプログラムの起動時にコードをランダムに配置
するASLR: Address Space Layout Randomization により減
少された。
スタック
リターンアドレス
XXXX
リタ ンアドレス
リターンアドレス
YYYYY
リタ ンアドレス
リターンアドレス
ZZZZ
スタックを攻撃
スタックフレームのリター
ンアドレスを積みなす
メモリ上のコード
XXXX‐8192 MOVE A,B
RET
…
ADD A,C
YYYYY‐8192
MUL A,B
RET
…
ZZZZ‐8192 MOVE B,C
RET
ASLRではメモリロードにアドレスを
ランダムに配置（ずらす）することで
ROPを意味のないものにする。

14. ASLRのイメージ
S のイメ ジ
• 仮想メモリ内の位置を移動(全体がランダムにならない)
– また アドレスビ トの変えられる位置は多くない
また、アドレスビットの変えられる位置は多くない
• 下位12bit (4KB)はページで固定。
• 上位はカーネル空間、ユーザ空間で切り分けている。
– Linux 32bitの場合、上位1GBがカーネル、下位3GBがユーザ。
0xFFFFFFFF
カーネル
１回目実行
２回目実行
３回目実行
0xC0000000
コード
ユーザ
ユ ザ
ヒープ
プ
スタック
コード
ヒ プ
ヒープ
スタック
コード
ヒープ
開始アドレス
が変わるのみ
が変わ
スタック
0x00000000
32ビットASLRでは数ビットを変えるのみでエントロピーを確保できない。

15. ASLR のランダムさの程度
• 「Windows Server 2012 R2 マイグレーション ガイド」より。
http://download.microsoft.com/download/0/7/B/07BE7A3C‐07B9‐4173‐B251‐6865ADA98E5D/WS2012R2_MigrationGuide_v2.0.docx
•
例：8 ビットの場合、256 通りの中から ベース アドレスが決まる
メモリ領域
Windows 7 および 2008 R2
Windows 8 および Windows Server 2012 以降
32 ビットプロセス
64 ビット プロセス
32 ビット プロセス
64 ビット プロセス
64 ビット プロセス
(HE 有効)
0 (ランダム化
なし)
0 (ランダム化
なし)
8
8
24
スタック
14
14
17
17
33
ヒープ
5
5
8
8
24
0 (ランダム化
なし)
0 (ランダム化
なし)
8
17
17
PEB、TEB
4
4
8
17
17
EXE イメージ
8
8
8
17 *
17 *
DLL イメージ
8
8
8
19 *
19 *
非 ASLR DLL イメー
イメ
ジ (オプト イン)
0 (ランダム化
なし)
0 (ランダム化
なし)
8
8
24
ボトム アップの割り当
て (オプト イン)
プ
トップ ダウンの割り当
て (オプト イン)
表: Windows 7 と Windows 8 の ASLR の⽐較、数字はエントロピーのビット数
* ベース アドレス 4 GB 未満の 64 ビット EXE には 8 ビット、64 ビット DLL には 14 ビットのエントロピーが適⽤される

16. ASLRの課題
• バイナリ自体をPIC(Position Independent Code)にする
必要あり。
• 絶対アドレスを指定されている古いバイナリはASLRを
活用できない。
ASLRはロ ド時のみに配置を 回変えるので、 度ア
• ASLRはロード時のみに配置を一回変えるので、一度ア
ドレスが漏えいしたら意味がない。
– ApacheなどForkのみでプロセスを多く派生するものは危険。
• Execすればよいが、多くは行っていない。
– Re‐Randomization の必要性
Re Randomi ation の必要性
• タネンバウム研のUSENIX‐SEC12論文
– Enhanced Operating System Security Through Efficient and Fine‐grained
Address Space Randomization
Add
S
R d i ti

17. Windowsのセキュリティ向上
XP SP0
XP XP2
Vista, 7
Win 8
DEP(software)
×
○
○
○
DEP(hardware)
DEP(h d
)
×
○
○
○
ASLR(stack)
×
×
○
◎
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%2F
monthly_research%2FMR201209_Windows8_Exploit_Mitigation.pdf&ei=t2DLUuPoL4SlkwXHsIHgCg&usg=AFQjCNGIBa1L4fHZrw7qHQhVRQWTYf2aTA&sig
2=btFLcMsnvqnEd5DyzKNMCw&bvm=bv.58187178,d.dGI

18. ASLRの次
Moving Target Defense
Moving Target Defense
• Moving Target Defense
Moving Target Defense
既存のシステムは同じ
存
じ
バイナリを使うので攻
撃対象になりやすい。
– 現在の攻撃は全てのマシンで同じバ
イナリが使われているため、既存
イナリが使われているため 既存
コード再利用攻撃を受けやすい。
– 個々のマシンで異なるバイナリにす
ることで、攻撃を難しくする。(多様性)
バイナリ自体がシステ
ム毎に変化することで
攻撃を回避する。
• Instruction Set Randomization
Instruction 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/

19. ISR: Instruction Set Randomization
• 既存のバイナリコードを等価な命令で置きかえること
でROPによるコ ド再利用を防ぐ。
でROPによるコード再利用を防ぐ。
今までの方式
ディスク
div b / 2
mul a x 2
mul a x 2
xor a, a
ret
ISR
実行
(ローダ)
div b / 2
mul a x 2
mul a x 2
mul a x 2
xor a, a
ret
メモリ
アドレス
コード領域
同じ命令が実
行される
div b / 2
mul a x 2
mul a x 2
xor a, a
ret
成功
メモリ内容
が全く違う
ディスク
div b / 2
mul a x 2
mul a x 2
xor a, a
xor a a
ret
実行
コード変換
div b / 2
l
mul a x 2
mul a x 2
xor a, a
ret
メモリ
アドレス
コード領域
等価な命令に置き
換えられる
shift l a
add a+a
Add a+a
mv 0, a
0
jump
攻撃者が同じ
コードを入手、
コ ドを入手
解析、攻撃
失敗
攻撃者が同じ
コードを入手、
解析、攻撃
• 問題点：セマンティックが変わらない場合 ROPに効
問題点：セマンティックが変わらない場合、ROPに効
果が無いのでは？評価が重要。

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

21. まとめ
• OS内のセキュリティ強化のアプローチは基本
キ
強
プ
基本
的に２つ
– それしか使えないか
• DEP S db A
DEP, Sandbox, Access Control, Code signing
C t l C d i i
– でたらめにするか
• ASLR, ISR (Instruction Set Randomization)