はじめに

このエントリでは、VEX (Vulnerability Exploitability eXchange) ドキュメントにおいてソフトウェア製品のステータス (status) が「NOT AFFECTED (影響を受けない)」の場合に使用することができる、事前に定義されたステータス根拠 (justification) をご紹介します。

VEX では、ソフトウェア製品における脆弱性の影響の有無を「ステータス」として明らかにすることが求められています。 ステータスは「NOT AFFECTED (影響を受けない)」「AFFECTED (影響を受ける)」、「FIXED (修正済み)」、「UNDER INVESTIGATION (調査中)」のいずれかになります。 VEX のコンテキストにおける「NOT AFFECTED」は、主に、脆弱性データベースと SBOM のマッチングにより検出されるものの、開発者によって影響を影響を受けないと確認された状態を指します。 ステータスが「NOT AFFECTED」の場合、ソフトウェア製品のユーザは、パッチ適用などのアクションを行う必要はないとされています。またステータス根拠はユーザが開発者による NOT AFFECTED の判断を理解する上での指標や、その判断を受け入れるかどうかの根拠となります。 このため、ステータス「NOT AFFECTED」とそのステータス根拠は重要なものとなります。

このエントリでは、米国の国土安全保障省 (DHS) サイバーセキュリティ・インフラセキュリティ庁 (CISA) によって公開された Vulnerability Exploitability eXchange (VEX) - Status Justifications を抄訳する形で、ステータスが「NOT AFFECTED」の場合に使用できる事前に定義されたステータス根拠をご紹介します。特に断りのない限り、以後の文章は先ほどの文書によるものとお考えください。ソフトウェア製品のインストレーションやデプロイメントには色々ありますが、このエントリでは Windows 環境における msi や exe を用いたインストールを行うソフトウェア製品を想定しています。

ステータス根拠の定義、図、および例について

事前に定義されたステータス根拠の一覧

「NOT AFFECTED」のステータス根拠のリストは次のとおりです。

• Component_not_present

  : 脆弱なコンポーネントは存在しない
• Vulnerable_code_not_present

  : 脆弱なコードは存在しない
• Vulnerable_code_not_in_execute_path

  : 脆弱なコードは実行パスに存在しない
• Vulnerable_code_cannot_be_controlled_by_adversary

  : 脆弱なコードへの入力は攻撃者に操作されない
• Inline_mitigations_already_exist

  : インラインの緩和策が既に存在する

各ステータス根拠に至るまでの流れ図

Component_not_present : 脆弱なコンポーネントは存在しない

このステータス根拠は、脆弱なコンポーネントが製品の配布パッケージに含まれておらず、製品が脆弱性の影響を受けない場合に使用できます。 根本的に製品に影響しないと判断できるものの、広範囲に影響があり危険性が高いため多くの注目を集めている脆弱性について、影響を受けないことを明確に宣言するために使用することが考えられます。 (注: 脆弱性の影響を受けないことが分かり切っているので、通常であれば無関係な脆弱性として何もしません。)

ステータス根拠「脆弱なコンポーネントは存在しない」の例には次のようなものがあります。

• 製品は Python と Elixir で記述されており、Java のコードは一切含まれていない。 従って、製品は Log4j の脆弱性の影響を受けるはずがない。 (注: log4shell のような社会的にインパクトのあった脆弱性に対する安全宣言のような使い方です)
• Java JAR ファイルは他の JAR ファイルを含むことが多いため、実際の存在の検証なしに自動化によってコンポーネントが JAR ファイルに存在するというフラグを誤って立てられています。 (注: 脆弱性スキャナーによる脆弱性の過剰検出に対する措置としての使い方です)
• コンテナイメージのベースレイヤには使用しないパッケージが含まれていることはよくあるが、上位レイヤはこれらのパッケージを削除することができます。 コンテナイメージには sudo が含まれていると考えられていましたが、展開前に削除されていました。 (注: これも脆弱性スキャナーによる脆弱性の過剰検出に対する措置としての使い方です)

Vulnerable_code_not_present : 脆弱なコードは存在しない

このステータス根拠は、脆弱性の原因となるコードが製品の配布パッケージに含まれておらず、製品が脆弱性の影響を受けない場合に使用できます。 「脆弱なコンポーネントは存在しない (Component_not_present)」とは異なり、脆弱性のあるコンポーネントというくくりでは製品プロジェクトに存在しているものの、脆弱性の原因となる部分(コード)が、プログラムのコンパイルなど様々な理由で配布パッケージから取り除かれている状態です。

このステータス根拠の例には次のようなものが含まれます。

• コンパイラによって関連する関数が削除された。 (注: ライブラリに含まれる脆弱性のある機能を使用しなかったので、コンパイルの時点でリンクされず製品パッケージから除外されたような場合の使い方です)
• 脆弱なコードはコンポーネントの新しいバージョンにおいて追加されたもので、製品に同梱されているバージョンには存在しない。

Vulnerable_code_not_in_execute_path : 脆弱なコードは実行パスに存在しない

このステータス根拠は、アプリケーションのコンテキストにおいて脆弱なコードが実行されることがない場合に使用できます。 この状況は、製品の配布パッケージに脆弱性のあるサードパーティ製ライブラリを含めているものの、脆弱性の無い機能のみを使用している場合などに発生する可能性があります。 なお攻撃者が実行パスを変更できる可能性があるため、単一の実行パスを想定してはなりません。

このステータス根拠の例には次のようなものが含まれます。

• 製品の配布パッケージに同梱された古い脆弱性を持つライブラリは、アプリケーションによって呼び出されることがない。 (注: 過去にライブラリを使用していて、バージョンアップによってそのライブラリを使用しなくなったものの配布パッケージから取り除かれなかったような状態です。)
• 製品パッケージに含まれている脆弱性のあるコンポーネントはパッチ適用で修復されているが、ロールバックのために脆弱性のある古いコンポーネントを残している。
• アプリケーションによって使用されることのない OS ユーティリティがコンテナイメージにデプロイされている。 これらのユーティリティはコンテナイメージから削除することはできないが、デプロイされたアプリケーションにおいていかなる用途でも使用されていない。
• インクルードされたライブラリには多くの関数が含まれていることがよくあります。 ライブラリにおいて直接的あるいは間接的に呼び出されることのない関数に存在する脆弱性もこのステータスとなります。 OpenSSL をセキュアな乱数生成器としてのみ使用するアプリケーションは、セキュアな乱数から呼び出されることのない Heartbleed の脆弱性に対して脆弱ではありません。
• 脆弱なコードは、インストールされていないハードウェアモジュールによってのみ実行される。

Vulnerable_code_cannot_be_controlled_by_adversary : 脆弱なコードへの入力は攻撃者に操作されない

このステータス根拠は、攻撃者が他の脆弱性を悪用することなしに、脆弱なコードへの入力を操作できない場合に使用できます。 製品の配布パッケージには、脆弱なコードを含むコンポーネントが存在します。 しかしながら、コンポーネントの使用状況により、攻撃者が脆弱なコードを悪用できないことがあります。

このステータス根拠の例には次のようなものが含まれます。

• 脆弱なコードへ渡す変数がハードコードされているため、外部からの入力を脆弱なコードへ渡すことができない。
• ソフトウェアに EternalBlue の脆弱性が存在するものの、SMB ポート 139 および 445 が無効化されていることに加え、ユーザがポートを有効化するために OS へアクセスすることができない。 ポートが使用できないため、脆弱性は攻撃者によって悪用されることはありません。 オペレータによる追加のアクションは必要ありません。

Inline_mitigations_already_exist : インライン緩和策が既に存在する

このステータス根拠は、製品に脆弱性の悪用を防止する組み込みの保護が含まれる場合に使用できます。 この組み込みの保護は、攻撃者によって覆されることはなく、ユーザによって無効化や変更されることもありません。 また組み込みの保護による緩和策は既知の攻撃方法に基づく悪用を完全に防止します。

注：緩和策は、ソフトウェアの脅威モデルがその保護を成功裡に実行することを可能にするシナリオにおいてのみ有効です。 あるソフトウェア・サービスで脆弱性を無効にする緩和策が、他のソフトウェア・サービスにおいて必ずしもそうであるとは限りません。

このステータス根拠の例には次のようなものが含まれます。

• 脆弱なコードより上流のコードで入力を無害化している
• ソフトウェアやハードウェアによるメモリ分離技術を使用したサンドボックスを使用している
• 脆弱なコードを含むコンポーネントの出力や影響を検証できる
• 二つの引数の内、片方が常に 1 であるため、乗算を原因とするバッファオーバーフローは発生しない
• ソフトウェアに EternalBlue の脆弱性が存在し、SMB ポートは有効になっているものの、ポートへのネットワークアクセスを遮断するファイアウォール構成がデバイスに統合されています。 ユーザは、通信を許可するように構成を変更するためのアクセス権限を持っていません。 デバイスのファイアウォールは、ポートへのアクセスを遮断することでインライン保護を提供します。 ユーザによる追加のアクションは不要です。

「脆弱なコードへの入力は攻撃者に操作されない」と「インラインの緩和策が既に存在する」の違いについて

ステータス根拠「Vulnerable_code_cannot_be_controlled_by_adversary」と「Inline_mitigations_already_exist」は似ているものの、いくつかの重要な違いがあります。 どちらも脆弱なコードが製品内に存在し、そしてそのコードを実行する可能性があります。 したがって、どちらのステータス根拠でも製品が実際に脆弱性の影響を受けないと判断するには、専門家による分析が必要となります。

脆弱なコードへの入力は攻撃者によって操作されないと判断した場合、脆弱性を悪用するために攻撃者ができることは何もないことを意味します。 一方、緩和策が既に存在すると判断した場合では、攻撃者は脆弱性を悪用するために製品へ影響を与える可能性はありますが、保護機構によって悪意のある動作はブロックされます。 事例の違いとしては、セクション 3.6 (注：脆弱なコードの入力は攻撃者に操作されない) の「外部からの入力を脆弱なコードへ渡すことができない」と、 セクション 3.7 (注：インラインの緩和策が既に存在する) の「脆弱なコードより上流のコードで入力を無害化している」が挙げられます。

まとめ

VEX のステータス「NOT AFFECTED」の事前に定義されたステータス根拠のドキュメントについて私見を交えて解説いたしました。皆様の理解の一助になれば幸いです。

更新履歴

• 2023年06月28日

  • 新規公開

参照

1. "Vulnerability Exploitability eXchange (VEX) - Status Justifications," Cybersecurity and Infrastructure Security Agency, June 01, 2022.