V. Security and Privacy

1. 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

2. 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) を利用

3. 脆弱性の例 脆弱性の要点： 1. config.inc.php には getConfigFile() から返る値を書き込む。 2. getConfigFile()では、$_SESSION[“ConfigFile0”][“Servers”]のキーの値$codeが返る。 3. $codeには、arbitrary_php_scriptを記述できる。

4. 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を再度行う

5. V4: Automated Software Architecture Security RiskAnalysis 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 をチェックするためのメタモデル (system-security metamodel) • SDM (system description model) と SSM (security specification model) を提案

6. 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

7. 評価方法 • 評価における問題 • アーキテクチャまで資料として残るプロジェクトの欠如 • 解決方法 • Manualでコードからアーキテクチャを復元 • 1万～40万行のオープンソースソフトウェア • 結果 • Precision, recall, f-measure のいずれも90%前後で検出 • アーキテクチャ等をmanualで作成しているので、ややbiasがかかっていると思うが、メタモデル(system-description model)に基づくOCLだけで、それだけ書けることが分かったことが重要（だと思う）