For1moc

前言#

この記事は、今年の USENIX で発表された php debloating に関する記事の前置き（略称 LIM、Less is More）です。

profiles：設定、シナリオ；profilling：分析（性能分析、行動分析など）；profiler：分析器

bloat：膨張；debloat：膨張を取り除く

ambient authority: 環境権限は、システムアクセス制御研究における用語です。主体が必要な対象の名前と、その対象に対して実行するアクションを指定することで、そのアクションを完了できる場合、主体は環境権限を使用していると呼びます。

monkey testing: 猿テストは、ユーザーがランダムな入力を提供し、動作を確認したり、アプリケーションやシステムがクラッシュするかどうかをチェックすることでアプリケーションやシステムをテストする技術です。Monkey テストは通常、ランダムな自動化ユニットテストとして実施されます。

Overview of paper#

この記事では、動的分析を利用して php web アプリケーションのコードカバレッジを取得し、未使用のコードを削除することで膨張を取り除くことを目的としています。

概括すると、以下のいくつかの部分があります：

1. CVE 脆弱性を選択し、web アプリにマッピングする
2. 4 つの異なるユーザーセットを選択し、アプリの使用をシミュレートする
3. コードカバレッジを記録し、未使用のファイル / 関数を分析する
4. カバレッジに基づいて debloat を行い、debloated アプリを得る（主にファイルレベルの debloating と関数レベルの debloating）
5. debloated アプリの通常の使用シミュレーションを行い、機能が正常であるか評価する
6. debloated アプリと元のアプリを同時に既知の CVE のエクスプロイトを行い、debloating の効果を評価する（つまり、debloating が脆弱性を引き起こす重要なコードを削除したかどうか）、およびその他の評価と比較を行う

ここには Figure 1 があり、誤字 Expoits があります。

background#

ソフトウェアの debloating の原理は、オペレーティングシステム（Linux カーネルから不要なコードを削除）、共有ライブラリ、およびコンパイルされたバイナリアプリケーションで成功しています。

この記事では、web アプリにおける debloating の適用性を評価し、脆弱性を引き起こす重要なコードを削除できるかどうかを検討します。

web debloating の motivation#

著者は Symfony の CVE-2018-14773 を用いて説明します。

このフレームワークは、悪用を引き起こす可能性のあるレガシーな IIS ヘッダーをサポートしています。サーバーがそのヘッダーを使用する必要がない場合、関連するサポートコードを削除することができます。つまり、debloating です。

目標 php web アプリ#

1. phpmyadmin：データベース管理
2. wordpress：ブログ管理
3. mediawiki：ウィキ管理
4. magento：e コマース管理

脆弱性マッピング至ソースコード#

各 web アプリは CVSS スコアに基づいて 20 の最もクリティカルな CVE を選択し、すべて 2013 年以降の CVE です。

異なる CVE の影響を受けるバージョンが異なるため、これらの CVE をすべて適用するために、複数のバージョンにまたがって脆弱性をマッピングする必要があります（以下の表参照）。

各 CVE が影響を与えるバージョンと行番号はデータベースに記録されています。

web app 使用シミュレーション#

以下の 4 つの方法でアプリの使用をシミュレートし、可能な限り広く深い機能カバレッジ、つまりコードカバレッジを達成します。

1. 一般的なチュートリアル（selenium スクリプトを使用）
2. monkey testing
3. クローラー
4. 脆弱性スキャン

web app コードカバレッジの記録#

php 分析器は php 拡張として提供され、原理は php エンジンを変更してコードカバレッジを収集することです。文中で使用されているのは XDebug です。

直接的な考えは、xdebug_start_code_coverage()とxdebug_get_code_coverage()を各 php ファイルの末尾に追加することですが、著者はいくつかの困難に直面しました。

任意の php ファイルがexit()またはdie()を呼び出して早期に終了できるため、上記の 2 つの記録関数を終了関数の前に追加する必要があります。

次に、shutdown 関数を登録し、それを shutdown 関数キューの末尾に追加する必要があります。

最後に、デストラクタです。クラスが shutdown 関数の後に破棄される場合、その部分はカバーされません。したがって、実行時に自分自身を登録するようにデストラクタを再実装しました。

Debloating 戦略#

1. ファイルレベルの debloat：実行されていない php ファイルを削除する
2. 関数レベルの debloat：ファイルレベルよりも細かい粒度の debloat で、関数内の未実行のコードブロックを削除できます。

ここでの debloating は、コードを完全に削除するのではなく、プレースホルダーに置き換えることです。これらのプレースホルダーにコードが実行されると、プログラムは終了し、関連する欠落関数の情報が記録されます。

その後、この方法が非常に効果的であることが証明され、多くの削除すべきでないファイル / 関数が記録されました。

実験結果#

コードの数量を測定する基準は単純なコード行数ではなく、Logical Lines Of Code（LLOC）であり、コメント、空行、必要な構文構造などの行数は含まれません。

明らかに、関数レベルの debloating はファイルレベルの debloating よりも多くのコードを削減しますが、これは 4 つの異なるプロジェクトのコード実践スタイルにも関連しています（たとえば、wordpress は外部パッケージにあまり依存せず、magento と mediawiki はよりモジュール化された方法で開発されています）。

1. サイクル複雑度の減少

サイクル複雑度（Cyclomatic complexity、CC）は条件複雑度とも呼ばれ、独立したパスの数として表現され、すべての可能な状況をカバーするために必要な最小限のテストケースの数として理解できます。

大三のソフトウェア工学の授業でこの概念を学んだことを発見しました。

debloat プロセス中にサイクル複雑度も低下し、アプリケーションの debloat 方法が複雑な命令や実行パスを削除できることを示しています。

2. debloating 後の CVE の減少

結果として、38% の脆弱性がファイルレベルの debloating によって削除され、10%〜60% は関数レベルの debloating によって削除されました（外部ライブラリが多い phpmyadmin と magento と、比較的単一の wordpress は 2 つの極端です）。

注意：ここで本文が考える脆弱性が debloat されたかどうかのルールは、元々ある脆弱性の利用がカバーしていたすべてのファイル / 関数が削除された場合であり、単にその一部を削除するのではありません（ほとんどの場合、これにより利用チェーンが破壊され、脆弱性が実際には利用できなくなります）。

この部分では、著者が debloating がどのように前述の 4 つのシナリオに基づいて行われた具体的なルールについて、明確に述べていないと感じます。

2 つの状況があります。一つは正常な使用で、脆弱性を引き起こさない（チュートリアルなど）、もう一つは意図的に脆弱性を利用する（脆弱性スキャンなど）か、アプリケーションを異常な状態にすることであり、monkey testing は同時に 2 つの状況を生み出します。

私は以下のルールに基づいて debloating が行われると仮定します：

• プログラムが正常に動作することを保証し、機能性と脆弱性を引き起こす可能性の衝突の中で機能性に譲歩すること。
• 正常に使用されているファイル / 関数以外のコードを削除すること。
• 悪意のある利用がカバーするパスと正常な使用がカバーするパスが部分的に重複している場合、非重複部分は削除され、重複部分は最初のルールの要件を満たして保持されること。

要するに、正常な使用がカバーしていないコードを削除する必要があります。

3. 異なる脆弱性タイプの影響

異なる脆弱性タイプの debloat の程度も異なります。たとえば、コマンド実行や SQL インジェクションなどの脆弱性は debloat しやすい（通常はあまり使用されないモジュールに存在することが多い）が、crypto や cookie 関連の脆弱性は debloat しにくい（主要な暗号化関数に存在し、削除できないコアコンポーネントに属する）。

4. POI 脆弱性のチェック

POI、すなわち PHP Object Injection は、CTF では PHP の逆シリアライズ脆弱性です。

著者は PHPGGC を使用し、POP 利用チェーンを生成するツールを使用して debloated アプリのエクスプロイトを行いました。

結果は、関数レベルの debloating が PHPGGC に存在する利用チェーンに対応する脆弱性をすべて削除したことを示しています（wordpress は外部ソフトウェアパッケージに依存していないため、ここには含まれません）。

5. dev パッケージの不適切な導入

composer はデフォルトで外部ソフトウェアを vendor ディレクトリに配置します。このディレクトリがサーバーの誤った設定によってアクセス可能な場合、RCE を引き起こす可能性があります（例えば PHPUnit）。

実験結果は、phpmyadmin と magento にこの問題が存在することを示しています。

6. 削除されたコードの定性的分析

削除されたファイルとコードが多すぎるため、この記事では k-means クラスタリングアルゴリズムを使用してファイルグループを生成し、TFIDF 最大頻度制限を使用して 50% 以上のファイルパスに出現する共通部分を無視します。

7. debloated アプリのエクスプロイトテスト

最後に、著者は metasploit フレームワークに存在するこの 4 つの php web アプリに対する CVE を収集し、公開された脆弱性情報に基づいて POC を作成しました。

元のバージョンの web アプリがすべて利用可能であることを確認した後、debloated バージョンをテストしたところ、半数が失敗しました（8 中 4）。

この結果は、debloating が web アプリのセキュリティ面において万能ではないものの、効果的であることを示しています。

性能分析#

コードカバレッジツールは性能にオーバーヘッドを追加するため、本節では XDebug ツールのオーバーヘッド分析を行います。つまり、selenium スクリプトが XDebug ありとなしで比較されます。

結果は、4 つの web アプリのオーバーヘッドが実行時間、CPU 消費、メモリ消費のすべてで増加したことを示しています。

ただし、このオーバーヘッドはカバレッジ計算方法を改善することで低減可能であり、たとえばオフラインでカバレッジを計算するなどの方法があります。この部分の作業は後で議論します。

限界と今後の作業#

前述の作業をまとめると、debloating は数十万行の無関係なコードを削減し、サイクル複雑度を 30%〜50% 削減し、CVE に関連する脆弱性の原因となるコードを約半分削除します。削除できない脆弱性に対しても、debloating は一部の gadgets を削除し、利用を難しくします。

著者は、この記事の作業がまだ不完全であり、以下の限界があると考えています。

1. 利用可能な脆弱性の不足

公開されている利用可能な脆弱性が不足しており、さまざまな脆弱性の利用再現や詳細説明などが含まれます。

著者は、web アプリ向けの自動利用スクリプト（BugBox など）が不足していることにも言及しています。これにより、研究者の作業が大いに助けられるでしょう。

2. 動的コードカバレッジ

web debloating は動的コードカバレッジ分析に大きく依存しており、4 つの再現可能で偏りのないアプリケーション使用構成シナリオがあっても、web アプリのすべての良性状態をカバーしているとは言えません。

要するに、カバレッジの深さが不十分であり、著者はクラウドソーシング（crowd sourcing）やユーザー研究（user studies）を通じてこれを追跡する予定です。

また、このパイプラインは特定のユーザーセットに対して不要な機能を削除するため、一般的な静的分析作業を行うことはできませんが、著者は debloating 後のコードに基づいて静的分析作業を行い、これらのユーザーセットにとって必要な機能が依然として存在することを確認できると提案しています。

3. 削除されたコードへのリクエストの処理

実際のユーザーが削除されたコードにリクエストを送信した場合、どのように処理しますか？単にアプリケーションを終了し、エラーを返すだけでは不十分です。削除されたコードを再導入し、ユーザーのリクエストを処理する必要があります。その前に、そのリクエストが悪意のあるものであるかどうかを確認する必要があります。

4. debloating の有効性を測る指標

この記事では、サイクル複雑度の減少、論理コード行（LLOC）の減少、CVE の減少、POP チェーンの 4 つの指標を使用してその有効性を測定しています。

しかし、各行のコードがプログラムの攻撃面に与える寄与は異なり、CVE の基準は専有ソフトウェアには適用できず、CVE は手動でマッピングして利用可能性を検証する必要があり、作業量が膨大です。

5. debloating の効率

モジュール化アプリケーションの debloating 効率は、単一アプリケーション（wordpress など）に比べて明らかに低下します。

関連作業#

ここで著者は、多くの静的分析の debloating 作業や、web クライアントの debloating 作業（chrome の攻撃面を減少させる）、およびカスタム php web アプリの動的分析作業（この作業の限界は、削除された脆弱性の数を定量的に特定できないことです）について言及しています。

まとめ#

私自身の考えのまとめは前述の Overview of paper に書いてあるので、ここでは原文の要約と結論を貼り付けます。

要約

ソフトウェアがますます複雑になるにつれて、その攻撃面が拡大し、さまざまな脆弱性の悪用が可能になります。Web アプリケーションも例外ではなく、現代の HTML5 標準と JavaScript の能力が利用されてリッチな Web アプリケーションが構築され、しばしば従来のデスクトップアプリケーションの必要性を超えています。この増加した複雑さに対処する 1 つの方法は、ソフトウェアの debloating プロセス、すなわち不要なコードだけでなく、特定のユーザーセットが必要としない機能に対応するコードの削除です。debloating はオペレーティングシステム、ライブラリ、コンパイルされたプログラムに成功裏に適用されてきましたが、web アプリケーションへの適用性はまだ調査されていません。本論文では、web アプリケーションの debloating のセキュリティ上の利点の最初の分析を提示します。私たちは 4 つの人気のある PHP アプリケーションに焦点を当て、クライアント側のリクエストの結果として実行されるサーバー側のコードに関する情報を取得するためにそれらを動的に実行します。私たちは 2 つの異なる debloating 戦略（ファイルレベルの debloating と関数レベルの debloating）を評価し、元のバージョンよりも 46% 小さく、元のサイクル複雑度の半分を示す機能的な web アプリケーションを生成できることを示します。さらに、私たちの結果は、debloating プロセスが歴史的な脆弱性に関連するコードを削除し、不要な外部パッケージや悪用可能な PHP ガジェットを削除することで web アプリケーションの攻撃面をさらに縮小することを示しています。

結論

本論文では、ソフトウェアの debloating と呼ばれるプロセスを通じて、現代の web アプリケーションにおける不要なコードの削除の影響を分析しました。私たちは、PHP アプリケーションがどのように使用され、クライアント側のリクエストの結果としてどのサーバー側のコードがトリガーされるかを記録することを可能にするエンドツーエンドのモジュラー debloating フレームワークのパイプラインの詳細を提示しました。コードカバレッジ情報を取得した後、私たちの debloating フレームワークは、ファイルレベルおよび関数レベルの debloating を使用してアプリケーションの未使用部分を削除します。4 つの人気のある PHP アプリケーション（phpMyAdmin、MediaWiki、Magento、WordPress）でフレームワークを評価した結果、web アプリケーションの debloating の明確なセキュリティ上の利点を目の当たりにしました。ファイルレベルの debloating で 9% から 64% の LLOC の顕著な減少を観察し、関数レベルの debloating でさらに最大 24% の減少を示しました。次に、外部パッケージが膨張の主要な原因の 1 つであることを示し、私たちの debloating フレームワークは Composer を使用したバージョンで未使用のコードの 84% 以上を削除できました。重要な CVE に関連するコードの削除を定量化することで、高影響の歴史的脆弱性の最大 60% の削減を観察しました。最後に、debloating プロセスが攻撃者がガジェットを構築し、POI 攻撃を実行するための主要なソースである命令やクラスを削除することも示しました。私たちの結果は、web アプリケーションの debloating が具体的なセキュリティ上の利点を提供し、したがって web アプリケーションの展開の攻撃面を削減する実用的な方法として真剣に考慮されるべきであることを示しています。