Nozomi Networks libfluid_msgライブラリは、OpenFlowネットワークパケットを処理するために使用されるlibfluid OpenFlowライブラリのコアコンポーネントである。注目すべきは、libfluidが2013年にOpen Networking Foundation(ONF)主催のOpenFlow Driver Competitionの勝者に選ばれたことだ。
これらの脆弱性は、単に不正な OpenFlow ネットワーク・パケットを送信することで悪用され、この脆弱なライブラリを利用しているネットワーク・コンポーネントに影響を与える可能性があるため、ネットワーク・インフラストラクチャに重大な影響を与える可能性があります。現在のところ、このライブラリがどの程度広く使われているのか、また、これらの脆弱性の影響を受ける可能性のあるすべての製品を測定することはできません。しかしながら、IT/OT マーケットで人気のあるベンダの新しい SDN ネットワークアプライアンスで使用されているのを見つけた後では、他のベンダも影響を受けている可能性が高い。この理由のために、私達は、私達の調査がベンダの間で彼らの OpenFlow 製品でこれらの脆弱性を緩和するように意識を高めることを望む。以下では、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はSoftware-Defined Networking (SDN)のキーテクノロジーで、スイッチやルーターなどのネットワークデバイスを中央から簡単に管理できるようにするものだ。当初はスタンフォード大学で開発され、現在はOpen Networking Foundationによって管理されているOpenFlowは、ネットワークの柔軟性を高め、変化するビジネスニーズに素早く対応することを可能にする。
OpenFlowはSoftware-Defined Networking (SDN) プロトコルである。
OpenFlowの核となる原理は、ネットワークのコントロール・プレーンとデータ(またはフォワーディング)プレーンを分離することだ。従来のネットワークでは、各スイッチやルーターはそれ自身のコントロール・プレーンを持ち、各アプライアンスはパケットをどこに送るかについて独立した決定を下す。OpenFlowは制御ロジックを一元化することで、この考え方を変えている。この新しいモデルでは、リモート・コンピューターで動作するコントローラーがOpenFlowプロトコルを使用して、ネットワーク・デバイス(スイッチなど)に転送の決定方法と、ネットワーク全体でトラフィック・フローがどのように処理されるべきかを指示する。この機能を活用することで、ネットワーク管理者はネットワーク・インフラ全体をリモートで統一された方法で設定することができ、ネットワークが変更された場合に各アプライアンスを手動で再設定する手間を省くことができる。
主要コンポーネント
この目標を達成するためには、コントローラがネットワークデバイスのフォワーディングプレーンに直接アクセスできるように、コントローラとフォワーダの間に通信標準を構築しなければならない。OpenFlowはこの標準を提供する。OpenFlowはフローテーブルという概念を導入している。フローテーブルは基本的にフォワーダがデータパケットの処理とルーティング方法を決定するために使用する命令セットである。OpenFlowプロトコルは、コントローラが特定のインターフェイスを通して、これらのフローテーブルをフォワーダにインストールすることを可能にする。そうすることで、コントローラーはネットワーク内でのデータの移動方法に直接影響を与え、制御することができる。これにより、ネットワークはより柔軟でプログラマブルになり、現在のネットワーク状況や要件に基づいたより効率的なルーティングが可能になる。
コントローラー
OpenFlow コントローラは SDN アーキテクチャの頭脳として働く。これは制御論理レイヤに位置し、OpenFlow プロトコルを通してデータ転送レイヤを管理するのに使われる。コントローラは通常2種類の論理インターフェースを提供する：
- ノースバウンド：このインターフェースは、ネットワークサービスやアプリケーションなど、コントローラの上に機能を構築するために開発者が使用するすべてのプログラミングインターフェースで構成されています。
- サウスバウンド：このインターフェイスは、ネットワークデバイスの動作をネットワークにプログラムするために、ネットワークデバイスとの対話を担当する。このチャネルを通して、コントローラはスイッチを管理・制御し、スイッチからのフィードバックも受け取る。OpenFlow チャネル上で交換されるメッセージは、OpenFlow プロトコルで指定されたフォーマットに従わなければならない。このチャネルは通常、トランスポート・レイヤー・セキュリティ (TLS) を使って暗号化されるが、TCP プロトコル上でプレーンテキストで直接実行することもできる。
フォワーダー
OpenFlow フォワーダは、物理的であれ仮想的であれ、OpenFlow ネットワークのコア・コンポーネントであり、データ層のフォワーディングを担当する。フローテーブルに基づいてパケットを転送する：
- マッチフィールド：受信パケットにマッチする。
- カウンタ：マッチしたパケットの統計情報を保持する。
- Actions：マッチしたパケットに対して何をするかを指定する(転送、ドロップ、変更など)。
フローエントリは、コントローラによって生成、維持、および配信される。OpenFlowフォワーダ(スイッチなど)は、マッチするフローエントリがない、見たことのないパケットを受信すると、このパケットをコントローラに送信する。次に、コントローラは、このパケットの処理方法を決定する。パケットをドロップすることもできるし、今後同じようなパケットをどのように転送するかをスイッチに指示するフローエントリを追加することもできる。
libfluid フレームワーク
Software-Defined Networking (SDN) プロトコルの採用を促進し加速するために、ONF は "OpenFlow Driver Competition" をオープンした。このコンペティションのゴールは OpenFlow のオープンソースライブラリの開発を促進することで、ネットワーク機器のベンダやオペレータからオープンソースプロジェクトまで、誰でも自由に使用できるようにし、OpenFlow プロトコルの実装に必要な参入コストと市場投入までの時間を削減することでした。コンペティションの結果、libfluid フレームワークが最優秀賞に選ばれました。
OpenFlowメッセージの構築
libfluid フレームワークは、ネットワーク・メッセージの作成と解釈のためのビルトイン・ツールを持たないユニークな設計になっている。その代わりに、開発者はハイレベルでユーザーフレンドリーな OpenFlow メッセージの表現で作業することができます。メッセージがネットワークから受信されると、開発者が理解し操作しやすい、よりわかりやすいフォーマットに変換されます。同様に、開発者がメッセージを送信する必要がある場合、同じように単純化されたフォーマットを使ってメッセージを作成します。高レベルオブジェクトはバイナリフォーマットに変換され、OpenFlowチャネルを通してネットワーク上に送信されます。
libfluid 自体はメッセージ処理機能を含まないが、この目的のために外部ライブラリの使用をサポートしている。libfluid_msgと呼ばれるそのようなライブラリの1つは、フレームワークと完全に互換性があり、OpenFlowメッセージを管理する直接的な方法を望む人のために用意されている。この柔軟性により、ユーザーは特定の要件に応じてセットアップをカスタマイズすることができる。
研究対象： libfluid_msg
私たちのセキュリティ研究の焦点は、libfluid フレームワーク内のスタンドアローン・メッセージング・ライブラリである libfluid_msg モジュールでした。このライブラリは、コントローラとスイッチ・エージェントの OpenFlow メッセージの作成と処理を簡素化することで、ネットワーク通信において重要な役割を果たします。このライブラリは、データのパッキング(マーシャリング)とアンパッキング(アンマーシャリング)のためのメソッドを提供するクラスによって、この目標を達成しています。オブジェクトがパックされると、正しいネットワークバイトオーダーでOpenFlowメッセージに変換され、ネットワーク上で送信できるようになります。逆に、アンパッキングでは、ネットワーク・データを解析し(必要に応じてバイトオーダーを調整し)、開発者が簡単に操作できるC++オブジェクトに変換します。
libfluid_msgのような構文解析ライブラリは、複雑なネットワークデータを管理可能なフォーマットに変換するという重要なタスクを処理するため、ネットワークプロトコルの中核的な役割を担っている。LogoFAILや ForcedEntryのようないくつかの有名なセキュリティ侵害は、構文解析ライブラリの弱点を悪用したものであり、構文解析ライブラリの開発における強固なセキュリティ対策の重要性を示している。
発見された脆弱性
Nozomi Networks 研究所は、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：不適切なヌル・ターミネーション (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++ クラスの "unpack" メソッドで特定されました。これらのソフトウェアの欠陥により、OpenFlow コントローラ/フォワーダが脆弱性のある libfluid_msg ライブラリを使用して悪意のある OpenFlow ネットワーク・パケットを処理すると、生バイトを処理するターゲット・アプリケーションでメモリ・リークやセグメンテーション・フォールトが発生する可能性があります。これらの問題により、OpenFlow コントローラ/フォワーダのネットワークを可視化できる攻撃者は、サービス拒否 (DoS) 攻撃につながる悪意のある OpenFlow ネットワークパケットを送信することができます。
情報開示のタイムライン
libfluid_msg ライブラリのセキュリティ脆弱性を発見した後、Nozomi Networks Labs は、これらの問題を報告するため、様々なチャネルを通じて ONF に何度か接触を試みました。また、CERT/CC の VINCE 報告プラットフォームを通じて連絡を取りましたが、ONF からの応答はありませんでした。その結果、このブログ記事を書いている時点では、libfluid_msg ライブラリのオープンソース・コードには、このブログ記事で取り上げた脆弱性のパッチが適用されていません。以下の表は、私たちの情報公開プロセスのタイムラインの概要です：
