Statically detecting vulnerability under memory pressure using

exhaustive search

安藤類央情報通信研究機構ネットワークセキュリティ研究所

2016 年暗号と情報セキュリティシンポジウム2016 年 1 月２２日（金）4C2 システムセキュリティ11:00--12:40

CVE-2013-4371 Realloc() vulnerability under high memory pressure

概要： プログラム全走査による Memory Pressure 下でのUse-After-Free (Heap Spray) 攻撃の検出と評価■ 近年、ミッションクリティカルな情報基盤ソフトウェアに適用される大規模なオープンソース（ Linux, Xen, Bind 等）に Use-After-Free (Heap Spray) の脆弱性が多々発見されている。

■ Use-After-Free (Heap Spray) は大量の動的メモリ操作によるフラグメンテーションの深刻化や初期化されないメモリ領域の発生が利用される。どちらも memory pressure を攻撃者が任意に発生させることができる状況で発生する。■ 本論文では、 memory pressure をかけやすい実装を LALR (Look-Ahead Left-Right) パーサ方式で記述し、ソースコードを全走査することで未知の脆弱性も含めた検出を可能にする手法を提案する。■ 評価実験では、 CVE-2013-4371 / CVE-2014-1950 を対象とし、 Use-After-Free 攻撃が発生する関数とループの解析と、コールチェインの全網羅による脆弱性の評価と、 Bind 上の未知の脆弱性の調査を行った。

未知の脆弱性の定義• 攻撃手法が未知で、探索 ( システム化）対象が未知量子暗号・新しい理論モデルへの攻撃等• 攻撃対象が既知で、探索対象が既知検出・対策済み• 攻撃対象が未知で、探索対象が既知ハッキング・新しいデバイス特有の攻撃 Android stagefright• 攻撃対象が既知で、探索対象が未知Use-after-free (heap spray) -> CVE-2013-4371 / CVE-2014-1950

攻撃対象 探索対象 　未知 未知 理論・ PoC既知 未知 未知の脆弱性未知 既知 ハッキング・ PoC既知 既知 既知の脆弱性

背景と設計方針 (Scalability vs False Negatives)In designing vulnerability checker, we face the difficult choice 　between precision and scalability. Particularly, security system 　design is forced to emphasize either false negatives or false positives. In todayfs large scale computing era, we conclude that a 　 false negative rate should be as close to 0 as possible.

As of January 2013, GitHub had grown to 3 million users and 4.9 million repositories (repositories are histories of code shared on the site). [9] And by December of this year, the company hit 10 million repositories.

http://slideplayer.us/slide/703331/

長期解析 ( 静的・形式手法）　

ITS4ACSAC 2000

MOPSCCS 2002

MC Meta-Level CompilationOSDI 2000

MACEConcolic ExecutionUSENIX SEC 2011

COTS (ROP)Usenix 2013

AutomationNDSS 2000

Format StringUSENIX SEC 2001

MOPS (2)CCS 2004

MetaSymsploitUSENIX SEC 2013

CHUCKYCCS 2013

Computational Verification (proverif)

CCS 2012

ConfAidOSDI 2011

Metal Compiler ExtentionSSP 2002

SLAMPOPL 2002

ForNox Hot SDN 2012

DowserUSENIX SEC 2013

F7 verificationCCS 2010

StackGuardUSENIX SEC 1998

Branch Tracing (ROP) Usenix Sec 2013

ProverifSSP 2006 プロトコル検証の精緻化

複合型

設定整合性

攻撃手法の迅速化への対応自動生成

形式手法

検査方法の分類■ 構文主導型 (Syntax Directed Translation)

　 - This translator consists of a parser (or grammar) with embedded actions that immediately generate output.

正規表現、有限オートマトンITS4: a static vulnerability scanner for C and C++ 　 code, Computer Security Applications, ACSAC 2002

Chucky: exposing missing checks in source code for vulnerability discovery ccs 2013

■ ルール方式 (Rule Based Translation)

- Rule-based translators use the DSL of a particular rule engine to specify a set of “this goes to that” translation rules.

遷移規則、プッシュダウンオートマトンUsing programmer-written compiler extensions to catch security holes SSP 2002

Checking system rules using system-specific, programmer-written compiler extensions OSDI 2000

■ モデル駆動方式 (Model Driven Translation)

- From the input model, a translator can emit output directly, build up strings, build up templates (documents with “holes” in them where we can stick values), or build up specialized output objects

モデル検査・ Concolic execution

MOPS: an infrastructure for examining security properties of software CCS2002

KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs, Usenix Sec 2011

Long term trend (検査方式・対象の分類）　

プロトコル検証

メモリ関連脆弱性オーバーフロー系

ルール・攻撃ペイロード自動生成

マッチングGREP

データベース

中間表現

モデル検査

Symbolic Execution

メモリ関連脆弱性DOS 攻撃

テンプレート関数型表現■ 脆弱性の性質の変化と検査方法のトレンド検査手法の性質の二極化。プロトコル（モデル駆動・形式手法）の精緻化と、大規模なテキストデータ・検索空間（パーサー・ファジング）の処理の大規模化

ITS4ACSAC 2000

ForNox Hot SDN 2012

Computational Verification (proverif)

CCS 2012

F7 verificationCCS 2010

MOPS (2)CCS 2004

MC Meta-Level CompilationOSDI 2000

COTS (ROP)Usenix 2013

ProverifSSP 2006

SLAMPOPL 2002

AEGNDSS 2012

ChimeraUsenix Sec 2012

CHUCKYCCS 2013

Use-after-free, Heap

Spray

Use-after-free, Heap

Spray

Heap Spray aka user-after-free

http://blog.tempest.com.br/breno-cunha/perspectives-on-exploit-development-and-cyber-attacks.html

create()

free()

realloc() use()

Jump to payloadon heap

ROP + Shellcode

int *tmp = (int*)realloc(k,(N+1)*sizeof(int)); if( tmp!=NULL ){ k = tmp; puts("________realloc(k)_________"); for(i=0; i<N+1; i++){ printf("&k[%d]:%p , k[%d]=%d\n",i,&k[i],i,k[i]); } }

realloc 関数は第一引数で渡したポインタのアドレス位置から拡張できない場合は新しい場所にメモリ確保を行う。

結果として、内容は保持されるがアドレスが変わる場合がある。

弊害：フラグメンテーションの深刻化・確保された場所は初期化が保障されない

検査対象　 CVE-2013-4371Xen Hypervisor

402 tmp = realloc(ptr, (i + 1) * sizeof(libxl_cpupoolinfo));

388libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool)389{390 libxl_cpupoolinfo *ptr, *tmp; 397 poolid = 0;398 for (i = 0;; i++) {399 info = xc_cpupool_getinfo(ctx->xch, poolid);400 if (info == NULL)401 break;402 tmp = realloc(ptr, (i + 1) * sizeof(libxl_cpupoolinfo));403 if (!tmp) {404 LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "allocating cpupool info");405 free(ptr);406 xc_cpupool_infofree(ctx->xch, info);407 return NULL;408 }409 ptr = tmp;410 ptr[i].poolid = info->cpupool_id;411 ptr[i].sched_id = info->sched_id;412 ptr[i].n_dom = info->n_dom;413 if (libxl_cpumap_alloc(ctx, &ptr[i].cpumap)) {414 xc_cpupool_infofree(ctx->xch, info);415 break;416 }417 memcpy(ptr[i].cpumap.map, info->cpumap, ptr[i].cpumap.size);418 poolid = info->cpupool_id + 1;419 xc_cpupool_infofree(ctx->xch, info);420 }

realloc use-after-free vulnerabilityUse-after-free vulnerability in the libxl\_list_cpupool function in the libxl toolstack library in Xen 4.2.x and 4.3.x, when running "under memory pressure," returns the original pointer when the realloc function fails, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors.

At line 402, Xen uses realloc for reallocating the memory. Note that the address of libxl\_cpupoolinfo is already assigned outside of this routine. Under high pressure, realloc can not extend the memory from the original pointer which is already obtained. in this case, realloc newly yielding the address which remaining the data to be written.

Boundary( 終了条件）が緩いループ　 (pressure をかけやすい）

Realloc の返り値がポインタ

提案手法 1 （ tagging, LALR parsing and binary search) Ａ－１対象となるソースツリーのファイルをリストアップする

Ａ－２ファイルリストから関数を tagging( 関数の行数など）するＢ－１対象となるソースツリーのループ群を検出するＢ－２対象となるソースツリーから realloc() 関数を検出するＣ－３　検出されたループそれぞれについて、関数の行数配列と、 realloc() の行数の間でバイナリサーチを行うＤ－１ＡからＣの手順をもとに、脆弱性についての情報をまとめる。

{ "_id" : ObjectId("5633ed7f42e0e0048307ec14"), "loop_end_line" : 420, "realloc" : 1, "loop_start_line" : 398, "loop_type" : 1, "realloc_line" : 402, "file_name" : "tools_libxl_libxl__c", "func_line_number" : 388 }

関数解析部分

ループ解析部分

出力例：深さ優先探索（幅２） libxl_list_cpupool

main_cpupoollist

libxl_list_cpupool

main_cpupoollist

main* 関数(libvirt のインターフェース）が連続している。

提案手法２ Loop representation and semantic action

66 line67: for_statement_168| for_statement_269| for_loop_start70| condition_171| condition_272| realloc73| block74;

258 block259: BRACE_LEFT {263}264|265 BRACE_RIGHT {266 counter = yylval.ival;269274 func_for_statement_end();275 func_for_statement_insert();276281 }

"for" { return FOR;}"realloc" { return REALLOC;}[0-9*] { return NUMBER;} "(" { return PAREN_LEFT;}

Ｌｅｘｅｒ ParserYacc or Bison Compiler

C Compiler

Parser Binary (a.out)

LR specification

y.tab.c

Input stream

y.tab.c

a.out

output stream

{ "_id" : ObjectId("5633ed7f42e0e0048307ec14"), "loop_end_line" : 420, "realloc" : 1, "loop_start_line" : 398, "loop_type" : 1, "realloc_line" : 402, "file_name" : "tools_libxl_libxl__c", "func_line_number" : 388 }

Semantic action

Bottom up

【参考】 比較した手法（ＳＣＩＳ２０１５）　：　プッシュダウンオートマトンによるブロック解析Main Loop

Lexer

NFA （有限オートマトン）PDA( プッシュダウンオートマトン）

Token Analyzer

Block Handler

識別子（制御文、メモリ操作命令など）の検出と処理

ブロック文（繰り返し、分岐）のネスト管理

Saturator-1lightweight code checker with document databasehttps://github.com/RuoAndo/Saturator-1

Iteration for each token

　　　　 switch (charatyp[ch]) fcase Letter:for ( ; charatyp[ch]==Letter ||

charatyp[ch]==Digit;ch=nextCh())if (p < p 16) p++ = ch;p = '\0'

if(strcmp(tkn.text, “for")==0)

Document Database処理系の状態情報（プログラム中の位置など）問い合わせ

格納

【参考】 評価実験 CVE-2013-4371 並列化したプッシュダウンオートマトン

12{"_id" : ObjectId("53f9ec4764e21cef244d69fb"), "located" : "402", "functionName" : "libxl_list_cpupool", "functionLine" : "388", "filename" : "libxl.c“}34{"_id" : ObjectId("53f9ec9464e21cef244d6a0e"), "start_line" : "398", "end_line" : "420", "functionName" : "libxl_list_cpupool", "functionLine" : "388", "filename" : "libxl.c“}

realloc

{"_id" : ObjectId("53d291fe40c2acf65bbbf9f7"), "located" : "145

"functionName" : "xc_vcpu_setaffinity", "functionLine" : "116", "filename" : "xc_domain.c" }

Use-after-free vulnerability in the libxl_list_cpupool function in the libxl toolstack library in Xen 4.2.x and 4.3.x, when running "under memory pressure," returns the original pointer when the realloc function fails, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors.http://www.cvedetails.com/cve/CVE-2013-4371/

We compiled our system on ubuntu12 LTS with Linux kernel 3.2.0. proposed system is hosted on Intel Xeon E5645 with 2.4 GHZ clock.

version forloop realloc functions real user sys real user sys

4.0.4 5438 76 13143m41.925s

0m9.213s 0m22.837 0m17.817s 0m2.880s 0m0.328s

4.1.0 5579 80 13735m35.133s

0m9.381s

0m25.002s 0m18.597 0m2.980 0m0.448

4.1.2 5547 76 13682m2.915s 0m9.301s

0m23.545s 0m18.432s 0m3.012 0m0.396

青：並列化なし　　赤：提案手法（タスク並列化）

評価実験（２） LALR(Look-Ahead Left-Right Parsing){ "_id" : ObjectId("5633ed7f42e0e0048307ec14"), "loop_end_line" : 420, "realloc" : 1, "loop_start_line" : 398, "loop_type" : 1, "realloc_line" : 402, "file_name" : "tools_libxl_libxl__c", "func_line_number" : 388 }

　 computing time

detected realloc() 　loop

detected loop

4.2.1 10m40.012s 21 　 3734

4.2.5 11.m17.259s 20 　 37374.2.5 11.m17.259s 20 　 3737

4.3.1 11m54.117s 18 　 3907

4.3.4 12m3.511s 18 　 3911

for_statement_1 : for_loop_start condition_1_1 condition_1_2 condition_1_3 { printf("for_statement type:1 starts at :"); print_line_number(); func_for_statement_1_start(); for_loop_flag = 1;} ;

for_statement_2: for_loop_start condition_1_1 condition_2_2 { printf("for_statement type:2 started at :"); print_line_number(); func_for_statement_2_start(); for_loop_flag = 1;} ;

終了条件 (boundary) が不十分なループ実装

提案した LALR 型は変数遷移やループ系特定可能だが reentrant(pure)ではないので現状では並列化できない。

Memory Pressure とコールチェイン解析libxl_list_cpupool

main_cpupoollist

libxl_list_cpupool

main_cpupoollist

version functions callchain (one edge) time4.1.0 804717 706252 9721m45.469s4.2.0 1190430 1032808 20923m4.443s4.3.0 1237690 1069749 22223m5643s

depth # callchains1 82 843 17554 52905 75246 88087 110648 124839 14424

1 2 3 4 5 6 7 8 90

2000

4000

6000

8000

10000

12000

14000

16000

# callchains

main* 関数(libvirt のインターフェース）が連続している。

未知の脆弱性： DNS Bind series の調査> db.bind_9_4_0_forloop.find(){ "_id" : ObjectId("5656562e208e132ac45177e1"), "filename" : "./bin/check/named-checkzone.c", "start_line" : 105, "end_line" : 136, "loop_type" : 2, "realloc" : 0, "realloc_line" : 0 }{ "_id" : ObjectId("5656562e208e132b4143cd11"), "filename" : "./bin/check/named-checkconf.c", "start_line" : 96, "end_line" : 101, "loop_type" : 1, "realloc" : 0, "realloc_line" : 0 }

> db.bind_9_3_0_forloop.find({"realloc":1, "loop_type":2}).count()39> db.bind_9_3_0_forloop.find({"realloc":1, "loop_type":1}).count()0> db.bind_9_4_0_forloop.find({"realloc":1, "loop_type":1}).count()0> db.bind_9_4_0_forloop.find({"realloc":1, "loop_type":1}).count()0> db.bind_9_9_8_forloop.find({"realloc":1, "loop_type":1}).count()0> db.bind_9_7_0_forloop.find({"realloc":1, "loop_type":1}).count()0> db.bind_9_9_8_forloop.find({"realloc":1, "loop_type":2}).count()64> db.bind_9_7_0_forloop.find({"realloc":1, "loop_type":2}).count()48

Hypervisor XenCVE-2013-4371 / CVE-2014-1950 に該当する realloc() の実装形態は発見されなかった。

まとめ： プログラム全走査による Memory Pressure 下でのUse-After-Free (Heap Spray) 攻撃の検出と評価■ 近年、ミッションクリティカルな情報基盤ソフトウェアに適用される大規模なオープンソース（ Linux, Xen, Bind 等）に Use-After-Free (Heap Spray) の脆弱性が多々発見されている。

■ Use-After-Free (Heap Spray) は大量の動的メモリ操作によるフラグメンテーションの深刻化や初期化されないメモリ領域の発生が利用される。どちらも memory pressure を攻撃者が任意に発生させることができる状況で発生する。■ 本論文では、 memory pressure をかけやすい実装を LALR (Look-Ahead Left-Right) パーサ方式で記述し、ソースコードを全走査することで未知の脆弱性も含めた検出を可能にする手法を提案する。■ 評価実験では、 CVE-2013-4371 / CVE-2014-1950 を対象とし、 Use-After-Free 攻撃が発生する関数とループの解析と、コールチェインの全網羅による脆弱性の評価と、 Bind 上の未知の脆弱性の調査を行った。