V3V4 - qwik.jp

V. Security and Privacy
本資料はICSE2013の以下の2件の論文の要約です。
Automated Software Architecture Security Risk Analysis using Formalized Signatures
Path Sensitive Static Analysis of Web Applications for Remote Code Execution Vulnerability Detection
V3: Path Sensitive Static Analysis of Web Applications for Remote
Code Execution Vulnerability Detection
 Background： RCE (Remote Code Execution) は重大な問題である。
– OWASPによると PHP ではもっとも流行した問題である
– XSS (Cross-site Scripting) の一種であるが、statefulなアタックである
– 文字列以外の値も扱う必要がある
 Related work：
– 静的文字列解析があるが、string constraintとnon-string constraintのmixed constraintを扱
えないものが多い
• CFG-basedのもの: path-sensitiveではない
– いくつか mixed constraint を扱えるものがあるが、不十分である
• Symbolic execution ベース文献[12][25]: 実行パスに対して解析 & 固定の文字列長
• Mixed constraint を一つの制約言語に変換文献[28]: non-string constraint に弱い
• 「limited」であると主張しているけど、具体的に扱えない例を出していない気がします。
 Approach:
– プログラムから string constraint / non-string constraint を区別して抽出し、iterative かつ
alternative な方法で解く
 Contributions:
– Context- and path-sensitive な静的解析であり、string solver と SMT solver を用いる方法
– プログラムを string / non-string な二つのサブプログラムへ分割して、それぞれの制約を抽出
し、これらの制約を同時に解く
– 10個のWebアプリに適用し21個のRCEを発見した。そのうち8個は未報告のものだった！
– その他いろいろ工夫： stateful な部分、ファイルの動的inclusion、など
 Evaluation:
– LLVMを利用(SSA変換のため)
– STP (non-string constraint solver) と HAMPI (string constraint solver) を利用
脆弱性の例
脆弱性の要点：
1. config.inc.php には getConfigFile() から返る値を書き込む。
2. getConfigFile()では、$_SESSION[“ConfigFile0”][“Servers”]のキーの値$codeが返る。
3. $codeには、arbitrary_php_scriptを記述できる。
Mixed制約解消のアルゴリズム
 前提:
– Loopはunrollする
– プログラムを string と non-string の部分に分割し、それぞれの制約を N, P とする
 手続き driver ：
– N を STP solver で充足判定
• UNSATなら安全(UNSAT)
• SATの場合、解（充足するassignment）をRとする
– P を HAMPI で充足判定
• UNSATなら安全(UNSAT)
– P を R の条件で HAMPI で充足判定
• SATならRを返す
 手続き iterSolver : 再帰的な手続きで充足するパス（変数への割り当て）を探す
– Rが空ならSを返す (Sは解)
– Rから一つずつ変数bと値bvを取り出して、
• b=bvをSに加えて P を S の条件で充足判定し SAT なら、b=bvをRから取り除いて
interSolver を行う
• b!=bvのときの N の充足判定を行い、UNSATなら UNSAT を返す
• b!=bvのとき、P についても同様に充足判定を行い、UNSAT なら UNSAT を返す
• b!=bvを除外して、interSolverを再度行う
V4: Automated Software Architecture Security Risk
Analysis using Formalized Signatures
 Background: 開発前におけるソフトウェアアーキテクチャのセキュリティ・レビューは重
要である。
– アーキテクチャの評価には大きく分けて、シナリオベースとメトリクスベースのものがある
– セキュリティの評価においては、特定の事前定義されたルールによって行われる
• 攻撃シナリオによる評価: セキュリティ上の要求や目的からシナリオを導出
• Security metricsによる評価: 決まったものが実装されている
 動機（扱う問題）:
– アーキテクチャを解析するツールがない
– アーキテクチャ評価基準を記述するための言語がない
 アプローチ:
– Attack scenario や security metrics / signature を OCL (Object Constraint Language) を用
いて記述し、attack scenario や security metrics を求める
– 脆弱性をOCLで書いてコード解析を行った研究の拡張
• M. Almorsy, J. Grundy, and A. S. Ibrahim, "Supporting Automated Vulnerability
Analysis using Formalized Vulnerability Signatures“, ASE, 2012, pp. 100-109.
 論文の貢献:
– OCLによる security signatures の記述方法
– OCLで記述された scenario や metrics signature をチェックするためのメタモデル (systemsecurity metamodel)
– SDM (system description model) と SSM (security specification model) を提案
ScenarioとMetricsの例
 Architecture Security Analysis Scenarios
– CAPEC (Common Attack Pattern Enumeration and Classification)のパターン
• 例： Man-in-the-Middle, Denial of Service, Data Tampering, Injection
 Architecture Security Metrics
– System Architecture Security Metrics
• These metrics can be used to assess the exposure, exploitability, and attack-ability
of the software system given its architecture, design, and may be code details.
• Attack Surface Metric, Compartmentalization Metric, Least Privilege Metric, Fail
Securely Metric
– Security Architecture Metrics
• Defense-In-Depth (Layered Security) Metric, Isolation Metric
評価方法
 評価における問題
– アーキテクチャまで資料として残るプロジェクトの欠如
 解決方法
– Manualでコードからアーキテクチャを復元
• 1万～40万行のオープンソースソフトウェア
 結果
– Precision, recall, f-measure のいずれも90%前後で検出
– アーキテクチャ等をmanualで作成しているので、ややbiasがかかっていると思うが、メタモデル
(system-description model)に基づくOCLだけで、それだけ書けることが分かったことが重要
（だと思う）

Download Report