Guardian: symbolic validation of orderliness in SGX enclaves
タイトル: Guardian: symbolic validation of orderliness in SGX enclaves
著者: Pedro Antonino, Wojciech Aleksander Woloszyn, A. W. Roscoe
Guardian
バイナリ解析フレームワークであるangr上に構築されたEnclave脆弱性検証ツール cipepser.icon SGX自体の脆弱性が対象です?一般の開発者が作成したSGXアプリケーションが対象?
jkcomment.icon どちらかというと一般の開発者が作成したSGXアプリケーション(ライブラリ)が対象ですね
Orderly Enclaveという概念を持つ
シンボリック実行を用いて、EnclaveバイナリをOrderly Enclaveに照らして検証し、メモリ破壊の脆弱性を検知する
EDL + edger8rの組み合わせで生成されたコード&機能を前提としている
Ordrely Enclave
典型的なEnclaveの動作をentry, secure, ocall,exitの4つのフェーズに分割し、各フェーズでは信頼できないメモリアクセスポリシーやサニタイズ条件の形で一連の制約をかける
https://gyazo.com/3564134acbe2ae887fbe3c9cb1335f8a
各フェーズはアドレスアノテーションで表す
Entry(EntryAddress, EntrySanitisationDone)
コンテキストスイッチ(アプリケーションからEnclave)
low levelでのサニタイズ実施(CPUレジスタのサニタイズとCPUフラグを初期化)
SDKが担当
cipepser.icon Intel SGX SDK?Guardianが提供するSDK?レジスタとかいじるし前者ですかね?
jkcomment.icon Enclaveを実装しているSDK(Intel STX SDKとかRUST SGX SDKけいとか)ですね
CPUレジスタのサニタイズ
Enclaveは、CPUレジスタが信頼された実行と信頼されていない実行の間で共有されるため
SGX SDKの場合、ランタイム・ライブラリであるtrusted runtime system (tRTS)がこのサニタイズを担当し、Enclaveに入るアセンブリ・ルーチンがこのタスクを実行
rbx, rdi, rsiなど
CPUレジスタフラグをクリア
AC, DF
low levelでのサニタイズが実行されるかどうかをチェック
全てのEnclave操作はEntryフェーズから始まらなければならない(スキップ不可)
Entryフェーズから遷移できるのはsecureとexitだけ
secure(SBegin1 , SEnd1), ... ...
ecallに相当
信頼できないメモリとの読み書き処理があるかをチェック
secureフェーズが終了したらexitフェーズに遷移
ocall
ocallに相当
信頼できないメモリとの読み書き処理が許可されている
ocalフェーズが終了したらsecureフェーズにreturn
exit
コンテキストスイッチ(Enclaveからアプリケーション)
low levelでのサニタイズが実行されるかどうかをチェック
secureフェーズが終了すると同時に実行される
仕組み
angrが提供している機能を用いてEnclaveバイナリを検証
SimProcedures
バイナリのシンボリック実行で特定のアドレスに到達したときに実行されるPython関数を作成
Hooking
特定のアドレスに関数を割り当てるプロセス
SimStateプラグイン
シンボリック実行の状態を拡張可能な変数
例
検証したいEnclaveバイナリをimport
SimProcedure ToSecureを実行するとTransitionAnnotation(EntryAddress, EntrySanitisationDone)の対応するアドレスにフックされる
Enclaveがエントリーフェーズまたは呼び出しフェーズのいずれかであるかどうかをチェック
エントリーサニタイズフラグが設定されているかどうかをチェック
Enclaveの実行状態はセキュアフェーズに切り替わる
Enclaveのスタックとヒープへの入力バイナリとサイズが与えられ、Enclaveのメモリ・レイアウトを決定し、エンクレーブのサイズ、ヒープのサイズ、Enclaveのベース・アドレスに対する開始オフセットを持つグローバル・データt構造と、スタックのサイズ、対応するスレッド制御構造(TCS)に対するオフセットを持つthread_data_t構造体を計測
cipepser.icon t構造はtypo?そういう構造がある?
jkcomment.icon
どのような脆弱性検出に役立つのか
Register sanitisation
Enclaveに入る前にアライメントチェック(AC)フラグが設定されていると,信頼されたEnclaveソフトウェアによって実行されたすべての非アラインドメモリアクセスが決定論的に通知される
ディレクションフラグ(DF)は、x86の文字列命令(rep movなど)のループ動作を自動インクリメントから自動デクリメントに変更するために設定できるもの。ecallの前にこのフラグが有効(クリアされていない)になっている場合、SGXのアドバイザはDFを予期しない「デクリメント」方向に変更し、Enclaveが実行する後続のすべてのx86ストリング命令の意図した方向を乗っ取る可能性がある。これにより、Enclaveのメモリ破壊や誤った計算結果を引き起こす可能性のある深刻な脆弱性が発生する
Memory range checking
あるメモリ範囲がEnclaveの内側にあるか外側にあるかを適切に確立できないと、信頼できないメモリに機密データを書き込んだり、攻撃者が制御する値を読み込んで分岐したりするような脆弱性が発生する可能性がある
メモリ範囲のチェックが行われていない、アドレス計算時のオーバーフロー
SDKのsgx_is_within_enclave、sgx_is_outside_enclave関数などの誤用
信頼されたメモリと信頼されていないメモリのバッファが重なると、両方のチェックに失敗し、仮にsgx_is_within_enclaveがfalseを返しても引数として渡されたメモリ範囲が完全にEnclaveの外にあると言えなくなる
cipepser.icon SGXで防いでほしい。ELRANGE内にあるチェックとかはするけど、範囲外のポインタを渡されること自体は防げないって感じなのかな。でも入力に依存するし、symbolic validationで防げるのか謎い
Nullポインタ逆参照
C/C++コードでは、ポインタが初期化されていないことを示すために、ゼロアドレスへのポインタであるnull-pointerの値を使用。プログラムがこのようなポインタを参照解除しようとすると、そのアドレスにメモリが割り当てられていない場合が多く、セグメンテーション・フォールト・クラッシュが発生。このため、このアドレスに対するポインタ範囲の検証は通常無視される。しかし、SGX のトラストモデルでは、攻撃者はプロセスの仮想メモリを操作して、アドレス 0 に何らかのメモリを割り当てることができます。そのため、攻撃者は、クラッシュの代わりに、このアドレスの値を操作して、Enclaveに望ましくない動作を実行させることができてしまう
Memory copying across trust boundary
評価
Intelが実装したArchitectural Enclave(AE)が提供している11個のecallから違反パターンは発見されなかった
一方で、Rust SGX SDKを使うライブラリから違反パターン発見
cipepser.icon 😢
global_init_ecall
いくつかのEnclaveのメタデータ情報(識別子とパス)を初期化するために使用
EDL + edger8rが生成したブリッジecall関数に対する引数がNULLの場合、信頼されているメモリへのコピーするコードは起動せず、NULLポインターがecall関数に渡される。したがって,ecall関数は,攻撃者が管理する通常のメモリバッファへのポインタで動作できてしまう
該当のプロジェクトのメンテナに連絡し、対応してもらった(これが問題であることに同意してくれた)
cipepser.icon エンクレーブとエンクレイブがあったので、直してしまったが、もしかして意図的でした?
jkcomment.icon 特に理由はないのですが、自動変換のせいな気がす
cipepser.icon ほむ
参考
Appendix
シンボリック実行
プログラム上の変数をシンボルとして扱い、シンボルに対する一連の操作を分析することで条件を満たす入力値を特定するプログラム解析手法
テストやファジングよりも遅いがカバレッジが良い
フォーマルな検証アプローチよりもカバレッジが悪いが速い
ディレクションフラグ(Direction flag)
アラインメントチェック(AC)フラグ
メモリチェックでアラインメントチェックが有効な場合にセットされる
code: alignment check
The x86 CPU contains a special bit flag in its EFLAGS register called the AC (alignment check) flag. By default, this flag is set to zero when the CPU first receives power. When this flag is zero, the CPU automatically does whatever it has to in order to successfully access misaligned data values. However, if this flag is set to 1, the CPU issues an INT 17H interrupt whenever there is an attempt to access misaligned data. The x86 version of Windows 2000 and Windows 98 never alters this CPU flag bit. Therefore, you will never see a data misalignment exception occur in an application when it is running on an x86 processor.
アラスメント
Enlcaveの脆弱性を特定する研究はいくつかある
Bulck
信頼されたコードと信頼されていないコードの間のインタフェースの設計不良がどのように脆弱性につながるかを分析
Enclaveに対する強力な攻撃に利用できる、多くの悪用可能な脆弱性を特定している
Guardianが一番影響の受けているプロジェクト
TeeRex
angrを用いたシンボリック実行により、Intel SGXのEnclaveにおけるメモリ破壊の脆弱性を発見するツール
Guardianと似たような機能を持つ
SGXBounds
異なるメモリセグメント(ヒープ、スタック、グローバルオブジェクト)に関する追加の境界メタデータをEnclaveに装備するフレームワークで、境界外の違反をランタイムに識別して処理することが可能
信頼されているスタックやヒープを含むバッファオーバーフローなど、Enclave内で行われる典型的なメモリ破壊攻撃を検出
Enclave Entry/Exit
https://gyazo.com/7e2247673bbce2404a19344c689279be
サニタイズ
アノテーション
あるデータに対して関連する情報を注釈として付与する