[論文レビュー] Cryptographic Path Hardening: Hiding Vulnerabilities in Software through Cryptography

Vijay Ganesh, Michael Carbin+1 more|arXiv (Cornell University)|Feb 2, 2012

Advanced Malware Detection Techniques参考文献 3被引用数 3

ひとこと要約

本稿では、脆弱性の原因となる条件分岐を、証明可能に安全な暗号化されたチェック（例：ハッシュ比較）に置き換えることで、ソフトウェアの脆弱性を隠す技術「暗号的パスハードニング」を提案する。これにより、静的解析による攻撃者がエクスプロイト条件を逆引きするのを計算的に不可能にする。この手法により、正確な発火条件を暴露せずにパッチを配布可能となり、リソース制限のある攻撃者にとってエクスプロイト開発のコストを実行不可能な水準まで引き上げる。

ABSTRACT

We propose a novel approach to improving software security called Cryptographic Path Hardening, which is aimed at hiding security vulnerabilities in software from attackers through the use of provably secure and obfuscated cryptographic devices to harden paths in programs. By "harden" we mean that certain error-checking if-conditionals in a given program P are replaced by equivalent" we mean that adversaries cannot use semi-automatic program analysis techniques to reason about the hardened program paths and thus cannot discover as-yet-unknown errors along those paths, except perhaps through black-box dictionary attacks or random testing (which we can never prevent). Other than these unpreventable attack methods, we can make program analysis aimed at error-finding "provably hard" for a resource-bounded attacker, in the same sense that cryptographic schemes are hard to break. Unlike security-through-obscurity, in Cryptographic Path Hardening we use provably-secure crypto devices to hide errors and our mathematical arguments of security are the same as the standard ones used in cryptography. One application of Cryptographic Path Hardening is that software patches or filters often reveal enough information to an attacker that they can be used to construct error-revealing inputs to exploit an unpatched version of the program. By "hardening" the patch we make it difficult for the attacker to analyze the patched program to construct error-revealing inputs, and thus prevent him from potentially constructing exploits.

研究の動機と目的

• 公開されたパッチやフィルタがエクスプロイト条件を露呈するリスクに対処すること。
• エラーを引き起こす入力を特定するためのプログラム解析を、暗号的スキームを破るのと同等に、証明可能に困難なものにする手法を開発すること。
• プログラムの正しさを損なわずに、実用的かつデプロイ可能な入力フィルタやパッチのハードニング手法を提供すること。
• 脆弱性の発火条件を隠すことで、ソフトウェアパッチの安全な配布を可能にすること。
• ソフトウェアセキュリティのモデルを、脆弱性検出が攻撃者にとって計算的に高価なものにシフトさせること。これにより、曖昧さや形式的検証に依存するのではなく、計算的困難性に依存する。

提案手法

• SHA-256やオブスカレートされたハッシュプリミティブなどの、証明可能に安全なハッシュ関数を用いて、脆弱なif分岐を同等のチェックに置き換える。
• 既知の悪意ある入力（例：'2250738585072011'）のハッシュ値を事前に計算し、ループによるハッシュ比較で入力の部分文字列と照合する。
• 小さな値の集合への属性チェック（例：x == v_i）を置き換えるために、排他的なハッシュ比較を用いる。
• ハッシュ関数の衝突耐性に依存することで正しさを保証し、誤検出の確率を極めて低く抑える。
• ハードニングされたバージョンが入力サイズに対して線形時間で実行され、定数倍の遅延しか生じないため、多項式時間の性能を維持する。
• 離散対数問題や因数分解問題などの暗号的仮定を活用し、ハードニングされたチェックを逆算することは、標準的な暗号プリミティブを破ることと同等に難しいと形式的に主張する。

実験結果

リサーチクエスチョン

• RQ1 暗号的オブスカリティを用いて、ソフトウェアパッチ内の脆弱性発火条件を隠すことは可能か？
• RQ2 静的解析やブラックボックステストによる逆引きが計算的に不可能な、ハードニングされた条件分岐を設計することは可能か？
• RQ3 ハードニングされた条件分岐が、最小限のパフォーマンスオーバーヘッドでプログラムの正しさを保つにはどうすればよいか？
• RQ4 実世界の脆弱性（例：PHPの浮動小数点パースバグ）に適用した場合、このアプローチの実用的限界は何か？
• RQ5 この技術は、入力フィルタだけでなく、プログラム内の他の非観測可能な定数の隠蔽にも一般化可能か？

主な発見

• PHP脆弱性用のハードニングされたフィルタは、選択したハッシュ関数の衝突耐性に起因する極めて低い誤検出確率で、悪意ある入力を正しく特定する。
• ハードニングされたフィルタのパフォーマンスオーバーヘッドは、元のバージョンと比較して定数倍の遅延に留まり、両者とも入力長に対して線形時間で実行される。
• 128ビットのハッシュを逆算するか、ブルートフォース検索を実行しない限り、攻撃者は悪意ある部分文字列 '2250738585072011' を回復できない。
• ハードニングされた条件分岐は、事前に計算されたハッシュ値を知らないとランダムな計算と区別がつかないため、半自動分析ツールがエクスプロイト発火入力を導出できない。
• このアプローチは、小さな値の集合や部分文字列のチェックに適用可能であり、特に推測が困難な値に対して特に有効である。
• この技術は、現代暗号と同様の証明可能なセキュリティ保証を提供し、エクスプロイトの発見がハッシュ衝突耐性などの標準仮定を破るのと同等に困難なものとなる。