Nozomi Networks Labs は、OpenFlow ネットワークパケットの処理に使用される OpenFlow ライブラリ libfluid の主要コンポーネントである libfluid_msg ライブラリに合計 37件の脆弱性があることを発見しました。注目すべきは、libfluid は 2013年に ONF (Open Networking Foundation) が主催する OpenFlow ドライバコンペティションの優勝者に選ばれたことです。
これらの脆弱性は、不正な OpenFlow ネットワークパケットを送信するだけで悪用できるため、ネットワークインフラに重大な影響を及ぼす可能性があります。この脆弱なライブラリを利用するあらゆるネットワークコンポーネントに影響を及ぼす可能性があります。現時点では、このライブラリの使用がどの程度広まっているか、また、これらの脆弱性の影響を受ける可能性のあるすべての製品を把握することはできません。しかし、IT/OT 市場で人気の高いベンダーの新しい SDN ネットワークアプライアンスで使用されていることが判明したため、他のベンダーにも影響がある可能性が高いと思われます。このため、私たちの研究がベンダーの皆様にこれらの脆弱性を緩和するよう促す一助となることを願っています。以下、OpenFlow プロトコル、libfluid フレームワーク、およびこれらの脆弱性を特定し公表するにあたり Nozomi Networks が実施した調査プロセスについて、より詳細な情報を共有します。
なぜそれが重要なのか
- SDN ネットワークへの影響が大きい：libfluid_msg ライブラリは、libfluid フレームワークを使用する SDN (Software-Defined Networking) 環境における OpenFlow メッセージの構築および解析に不可欠です。このライブラリに脆弱性があると、OpenFlow ネットワークノード (コントローラやフォワーダなど) のコア機能が危険にさらされる可能性があります。
- 潜在的に悪用の可能性がある：攻撃者は、OpenFlow プロトコルメッセージの解析に libfluid_msg ライブラリに依存している SDN ネットワークアプリケーションをクラッシュさせるために、これらの脆弱性を容易に悪用することができ、DoS 攻撃につながります。
何をすべきか？
Open Networking Foundation に通知したにもかかわらず、公式のパッチはリリースされていません。そのため、このライブラリを OpenFlow 製品で使用しているベンダーには、潜在的なリスクを軽減するために、以下の積極的な対策を講じることを推奨します。
- libfluid_msg ライブラリのバグを見つけ、自分で修正する。
- ネットワークアクセス制御を実装してアクセスを分離する。脆弱な libfluid_msg ライブラリを使用している OpenFlow ノードが、信頼されていないネットワークからアクセスできないようにする。
OpenFlow プロトコル
OpenFlow は、スイッチやルーターなどのネットワーク機器を中央の場所からより簡単に管理できるようにする、SDN (ソフトウェア定義型ネットワーキング) の主要技術です。当初はスタンフォード大学で開発され、現在は Open Networking Foundation が管理している OpenFlow により、ネットワークはより柔軟になり、変化するビジネスニーズに迅速に対応できるようになります。
OpenFlow は SDN プロトコルである
OpenFlow の根幹をなす原則は、ネットワークのコントロールプレーンとデータ (または転送) プレーンを分離することです。従来のネットワークでは、各スイッチやルーターが独自のコントロールプレーンを備えており、各機器がパケットの送信先を独自に決定していました。OpenFlow は、コントロール・ロジックを一元化することで、この考え方を変えています。この新しいモデルでは、リモートコンピュータ上で稼働するコントローラが、OpenFlow プロトコルを使用して、ネットワークデバイス (スイッチなど) に転送の決定方法と、ネットワーク全体でのトラフィックフローの処理方法を指示します。この機能を活用することで、ネットワーク管理者がネットワークの変更時に各アプライアンスを手動で再設定することなく、ネットワークインフラ全体をリモートで統一的に構成することが可能になります。
主要コンポーネント
この目標を達成するには、コントローラがネットワークデバイスの転送プレーンに直接アクセスできるように、コントローラとフォワーダーの間に通信規格を構築する必要があります。OpenFlow はこの規格を提供します。OpenFlow では、フローテーブルという概念が導入されています。フローテーブルは、フォワーダーがデータパケットの処理とルーティング方法を決定するために使用する一連の命令です。OpenFlow プロトコルにより、コントローラは特定のインターフェースを介して、これらのフローテーブルをフォワーダーにインストールすることができます。これにより、コントローラはネットワーク内でのデータの移動方法を直接的に影響し、制御することができます。これにより、ネットワークはより柔軟かつプログラム可能になり、現在のネットワークの状態や要件に基づくより効率的なルーティングが可能になります。
コントローラー
OpenFlow コントローラは、SDN アーキテクチャの頭脳として機能します。制御論理層に位置し、OpenFlow プロトコルを通じてデータ転送層を管理するために使用されます。コントローラは通常、2種類の論理インターフェースを提供します。
- ノースバウンド：このインターフェースは、ネットワークサービスやアプリケーションなど、コントローラの上に機能を構築するために開発者が使用するすべてのプログラミングインターフェースで構成されています。
- サウスバウンド：このインターフェースは、ネットワークデバイスとやり取りし、その動作をネットワークにプログラムする役割を担っています。このチャネルを通じて、コントローラはスイッチを管理・制御し、スイッチからのフィードバックも受け取ります。OpenFlow チャネルでやり取りされるメッセージは、OpenFlow プロトコルで指定されたフォーマットに従う必要があります。このチャネルは通常、TLS (Transport Layer Security) を使用して暗号化されますが、TCP プロトコル上で平文で直接実行することも可能です。
フォワーダー
OpenFlow フォワーダは、物理的であれ仮想的であれ、OpenFlow ネットワークのコア・コンポーネントであり、データ層のフォワーディングを担当する。フローテーブルに基づいてパケットを転送する：
- マッチフィールド：受信パケットにマッチする。
- カウンタ：マッチしたパケットの統計情報を保持する
- アクション：マッチしたパケットに対して何をするかを指定する (転送、ドロップ、変更など)
フローエントリはコントローラによって生成、維持、配信されます。OpenFlow フォワーダー (スイッチなど) が、これまでに見たことのないパケットを受信し、そのパケットに一致するフローエントリがない場合、そのパケットをコントローラに送信します。コントローラは、このパケットをどのように処理するかを決定します。パケットを破棄することもできますし、今後同様のパケットを転送する方法をスイッチに指示するフローエントリを追加することもできます。
libfluid フレームワーク
SDN (ソフトウェア定義ネットワーキング) プロトコルの採用を促進し、加速させるため、ONF は "OpenFlow Driver Competition" を開催しました。このコンペティションの目的は、ネットワーク機器ベンダーやオペレーターからオープンソースプロジェクトまで、誰もが自由に利用できる OpenFlow オープンソースライブラリの開発を促進し、OpenFlow プロトコルの実装に必要な初期コストと市場投入までの時間を削減することでした。コンペティション終了後、libfluid フレームワークがコンペティションの勝者に選ばれました。
OpenFlow メッセージの構築
libfluid フレームワークは、ネットワークメッセージの作成や解釈を行う組み込みツールを持たない独自設計となっています。その代わり、開発者は OpenFlow メッセージの高レベルでユーザーフレンドリーな表現を使用して作業することができます。ネットワークからメッセージを受信すると、開発者が理解し操作しやすいよりシンプルな形式に変換されます。同様に、開発者がメッセージを送信する必要がある場合、同じ簡素化された形式を使用してメッセージを作成します。高レベルのオブジェクトはバイナリ形式に変換され、OpenFlow チャネルを通じてネットワークに送信されます。
libfluid 自体にはメッセージ処理機能は含まれていませんが、この目的のために外部ライブラリの使用をサポートしています。libfluid_msg と呼ばれるそのようなライブラリは、フレームワークと完全に互換性があり、OpenFlow メッセージを直接管理したい方にご利用いただけます。この柔軟性により、ユーザーは特定の要件に応じてセットアップをカスタマイズすることができます。
研究対象： libfluid_msg
Nozomi Networks Labs のセキュリティ研究の焦点は、libfluid フレームワーク内のスタンドアロン型メッセージングライブラリである libfluid_msg モジュールでした。このライブラリは、コントローラやスイッチエージェント向けの OpenFlow メッセージの作成と処理を簡素化することで、ネットワーク通信において重要な役割を果たします。このライブラリは、データのパッキング (マーシャリング) とアンパッキング (アンマーシャリング) のメソッドを提供するクラスを通じて、この目標を達成します。オブジェクトがパッキングされると、正しいネットワークバイトオーダーで OpenFlow メッセージに変換され、ネットワークに送信可能な状態になります。逆に、アンパッキングでは、ネットワークデータを解析し (必要に応じてバイトオーダーを調整)、開発者が簡単に操作できる C++ オブジェクトに変換します。
libfluid_msg のような解析ライブラリは、複雑なネットワークデータを管理可能なフォーマットに変換するという重要なタスクを処理するため、ネットワークプロトコルにおいて中核的な役割を担っています。適切に保護されていない場合、解析ライブラリは重大な脆弱性にもなり得ます。LogoFAIL やForcedEntryなどの著名なセキュリティ侵害の多くは、解析ライブラリの脆弱性を悪用したものであり、解析ライブラリの開発における強固なセキュリティ対策の重要性を示しています。
発見された脆弱性
Nozomi Networks Labs は、libfluid_msg ライブラリに影響する合計 37件の脆弱性を特定しました。これらは、以下の共通脆弱性識別子 (CWE) と対応する CVSSv3.1 スコアでグループ化できます。
- CWE-125：境界外読み取り (27)
- CVSSv3.1中 (6.5) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
- CWE-690：NULL ポインタ参照への戻り値の未チェック (9)
- CVSSv3.1中 (5.3) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
- CWE-170：不適切な NULL ターミネーション (1)
- CVSSv3.1：中 (5.3) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
影響と攻撃シナリオ
これらの脆弱性は、OpenFlow コントローラ/フォワーダからネットワーク経由で受信した生のバイト列をアンマーシャルし、OpenFlow メッセージを表す対応する C++ オブジェクトに変換する C++ クラスの "アンパック" メソッドで確認されています。このソフトウェアの欠陥により、OpenFlow コントローラ/フォワーダーが脆弱な libfluid_msg ライブラリを使用して悪意のある OpenFlow ネットワークパケットを処理した場合、生バイトを処理する対象アプリケーションでメモリリークやセグメンテーションフォールトが発生する可能性があります。これらの問題により、OpenFlow コントローラ/フォワーダーにネットワーク経由でアクセスできる攻撃者は、悪意のある OpenFlow ネットワークパケットを送信してDoS (サービス拒否) 攻撃を仕掛けることができます。
情報開示のタイムライン
libfluid_msg ライブラリのセキュリティ脆弱性を発見した後、Nozomi Networks Labs は、これらの問題を報告するために、さまざまなチャンネルを通じて ONF に連絡を試みました。また、CERT/CC の VINCE 報告プラットフォームを通じて連絡を取ろうとしましたが、ONF からの回答はありませんでした。その結果、本ブログ記事執筆時点において、libfluid_msg ライブラリのオープンソースコードには、このブログ記事で取り上げた脆弱性に対する修正が施されていません。以下の表は、当社による情報開示プロセスのタイムラインの概要を示しています。
