組み込みシステムやIoT デバイスは、非常に限られた処理能力、メモリ、ストレージで動作することが多い。OpenSSL、MbedTLS、WolfSSLのような標準ライブラリは堅牢でよくテストされていますが、オーバーヘッドが多すぎることがあります。このため、医療モニターや産業用制御システムのように、侵害や混乱を防ぐために信頼性と応答性が重要な環境では実用的ではありません。
Mongoose Web Server Libraryが提供するような軽量TLS実装は、これらのデバイスのニーズを満たすように特別に設計されており、限られたリソースに負担をかけることなくセキュアな通信を可能にする。
Nozomi Networks Labsは、Mongooseが多くのデバイスで重要な役割を担っていることを認識し、このライブラリを使用しているすべての製品のセキュリティ体制を改善するため、綿密な分析を実施しました。このライブラリは、HTTPSサーバーのようなデータ伝送を保護し、機密情報を保護するために不可欠な機能を備えています。
この脆弱性は、慎重に細工した悪意のあるTLSパケットをターゲットデバイスに送信することで悪用できます。特別に細工したTLSメッセージを送るだけで、攻撃者はMongooseライブラリを使うデバイスをクラッシュさせることができる。
MongooseプロジェクトのベンダーであるCesanta社は、重大なリスクを考慮し、Mongoose v7.15を迅速に開発した。この新しいリリースには、私たちが発見した問題に対処するためのすべてのパッチが含まれています。
このブログポストでは、Mongoose Web Server Libraryに関する私たちの研究の主なハイライトを紹介します。私たちがどのようにしてこれらのセキュリティ欠陥を発見したかを説明し、IoT デバイスへの影響について議論し、より広範なセキュリティIoT エコシステムにどのような意味があるかを探ります。
研究範囲
Mongooseは組み込みシステム用の軽量なオープンソースネットワーキングライブラリで、HTTP、WebSocket、TLSなどのプロトコルを管理します。このプロジェクトは現在GitHubで11kスターに達し、世界中の何億ものデバイスにデプロイされています。その人気のため、シーメンス、シュナイダーエレクトリック、ボッシュ、さらには国際宇宙ステーションで使用されているNASAなどの大手企業からも信頼されている。
Mongooseを運営するCesanta社は、セキュリティを非常に重視している：
- MongooseリポジトリはGitHub上の継続的インテグレーションシステムを使用しており、コミットごとに何百ものユニットテストを実行し、最新のアドレスサニタイザー技術を活用してセキュリティの脆弱性を早期に特定する。
- MongooseはGoogleのoss-fuzzと統合されている。oss-fuzzは潜在的な脆弱性を積極的にスキャンする継続的なファザーで、ライブラリが新たなセキュリティ問題に対して継続的に監視されることを保証する。
- Cesanta は、Cisco Talos、Microsoft Security Response Center、MITRE Corporation、Compass Security などの独立系セキュリティ組織から脆弱性レポートを受け取っている。
Cesantaは、セキュリティのあらゆる側面を注意深く処理していますが、調査中に、組み込みのTLSプロトコル実装がファズテストのパイプラインに統合されていないことを確認しました。TLS（Transport Layer Security）は、クライアントとサーバー間で安全なHTTPS接続を確立し、データの機密性と完全性を保証する基本的な役割を果たすプロトコルです。TLSライブラリに脆弱性があれば、深刻な影響を及ぼす可能性がある。
TLSネットワーク・プロトコルが果たす重要な役割のため、このTLS実装に依存するデバイスの安全性を低下させる可能性のある、メモリ破壊や不適切な入力処理などの隠れた脆弱性を発見することを期待して、そのセキュリティ態勢を調査することにした。
これらの脆弱性の影響は？
Mongoose Web Server Libraryの最新バージョン7.14を分析した結果、TLSネットワークプロトコルのコードに関連するメモリ破壊の脆弱性を10個発見しました。この脆弱性が悪用されると、組み込み機器やIoT 。
以下は、発見された脆弱性のハイレベルな影響の一部である：
- デバイスのクラッシュや不安定性：多くの脆弱性（CVE-2024-42386 など）は、攻撃者が送信した不正な TLS パケットを読み取ることでトリガーされる可能性があります。これによりシステムがクラッシュし、予期せぬシャットダウンや連続的な再起動につながる可能性があります。
- サービス拒否（DoS）：CVE-2024-42384の脆弱性を悪用することで、攻撃者はデバイスが予期しないTLSパケットを適切に処理できないことを悪用し、デバイスを過負荷状態に陥らせ、応答不能にさせる可能性があります。病院や工場などのクリティカルな環境では、この種の攻撃は深刻な安全上の問題につながる可能性があります。
これらの脆弱性は、デバイスが無人で動作することが多いIoT 環境にとって特に懸念すべきものであり、侵害された1台のデバイスが、接続されたシステムのネットワーク全体を混乱させる可能性がある。これらの脆弱性に対処することは、ヘルスケア、スマートホーム、産業オートメーションなどの重要な分野で信頼性の高い安全な運用を確保するために不可欠である。
脆弱性リストと影響を受けるバージョン
次の表は、Nozomi Networks Labs がこの脆弱性調査中に Mongoose Web Server v7.14 で発見したすべての脆弱性の一覧です：
脆弱性スポットライト
MongooseライブラリーはGoogleのOSS-Fuzzプロジェクトに統合されているが（Cハーネスコードはここにある）、既存のハーネスではTLS関数が一つもテストされていないことに気づいた。この観察により、私たちはTLS攻撃サーフェスに注目することになった。TLS攻撃サーフェスは、ターゲットにネットワークアクセスできる攻撃者によって悪用される可能性のある興味深いベクトルだからだ。
TLSスタックの実装をファジングするのは難しいことで知られている。TLSは本質的にステートフルであり、ハンドシェイク、キー交換、データ送信といった複数の段階を経て進行する。このようなステートフルなプロトコルをテストするための有効なテストケースを自動的に生成するには、さまざまなシナリオを効果的に評価するために、メッセージの正しいシーケンスと状態を保持する必要があります。プロトコルが各ステップで有効な状態であることを保証するのは複雑であり、特にファズテスト中に異なる入力が状態遷移に影響を与える可能性があるためです。
この複雑さを考慮し、私たちはより単純なアプローチを選んだ。まずMongooseのTLSソースコードを解析して、最初のTLSパケットがクライアントやサーバーのどこでどのように受信されるかを理解することから始めた。関係する主要なデータ構造を特定し、クライアントまたはサーバーが最初のTLSパケットを処理するときの内部状態を調べた。この理解をもとに、これらのデータ構造を有効な内部状態で初期化し、ランダムなTLSパケットを提供し、この入力を処理する最初のTLS関数を呼び出すテストケース・ジェネレーター（Cハーネス）をコーディングした。
分析の結果、クライアントとサーバーの両方が以下のデータ構造を利用していることが判明した：
struct tls_data構造体 mg_connection
これらの構造体は、通信のクライアント側を表すかサーバー側を表すかによって初期化方法が異なる。どちらのTLSピアも mg_tls_handshake 関数は、TLS通信フロー全体を管理する。この関数は、受信するTLSネットワーク・パケットを rtls のフィールドにある。 mg_connection 構造体を作成し、受信したパケットに基づいてTLSハンドシェイクを継続する。
この情報を念頭に置いて、私たちは次のようなハーネスコードを作成した：
このコードの背景にあるコンセプトは単純で、以下のステップでまとめることができる：
- を初期化することで、模擬TLSクライアント接続をセットアップする。
tls_dataそしてmg_connection構造体を適切な値で再作成し、有効なTLS初期状態を再現する。 - について
c.rtlsバッファはランダム化されたTLSパケットで感じられる。 - について
mg_tls_handshake関数が呼び出され、ファジング入力は通常のTLSハンドシェイク時と同じように処理される。
初期パケット処理に焦点を当てることで、ファジング中にTLSの完全なステートマシンを維持する複雑さを回避し、プロトコルシーケンス全体をシミュレートする必要なく、不正なパケットや予期しない初期パケットによってトリガーされる可能性のある脆弱性について、TLS実装を効果的にテストすることができます。
ファザーをしばらく実行した後、次のようにして障害が検出された。 アドレスサニタイザー (ASAN）。この事故は、以下のような貴重な洞察をもたらしている：
の読み取り操作によるヒープバッファオーバーフローが報告された。 gcm_update 関数を使用している。無効な読み出しは、割り当てられたバッファのすぐ先で発生しており、オフバイワンエラーか、バッファ境界の計算が間違っていることを示唆している。クラッシュの原因を理解するために、我々は mg_tls_recv_record 関数で最初の復号化が行われる。関連するコードの一部を以下に示す：
この関数を分析したところ、この関数は リオ->ブフ[3:4］ バイトで計算する。 msgsz 値である：
msgsz =MG_LOAD_BE16(rio->buf + 3)；次に、クライアントまたはサーバーが復号アルゴリズムとしてAES GCMを使用する場合、両者はともに mg_aes_gcm_decrypt に16を引く関数である。 msgsz 値である：
mg_aes_gcm_decrypt(msg, msg, msgsz - 16, key, 16, nonce, sizeof(nonce))；しかし、ここで問題がある。 msgsz が16より小さい場合、16を引くと整数のアンダーフローが発生し、折り返しによって正数が大量に発生する。このエラーの結果は mg_aes_gcm_decrypt 関数は 入力長 よりも大きな値である。 リオ→ブフ TLSバッファ。そして gcm_update 関数が全バイトを反復処理すると、out-of-bound readがトリガーされ、バイナリ・アプリケーションのセグメンテーション・フォールトが発生する。
クラッシュの背後にある理由を確認した後、このバグにつながる悪意のあるTLSパケットをさらに調査することにした。以下の証拠に示すように、TLS Client Helloパケットの「length」フィールドには16より小さい値がない。 mg_tls_recv_record 関数である。
しかし、よく見ると mg_tls_recv_record を設定していることがわかった。 リオ→ブフ TLSバッファは、TLSクライアントHelloパケットの先頭ではなく、そのTLSハローパケットの先頭である。 エクステンド フィールドにいる：
このフィールドの5バイト目を読み取ることで、この関数はこのフィールドを初期化に使用する。 msgsz 変数を0x5に変換する。この動作により、この変数に 16 を引いた後、整数のアンダーフローが発生する：
修復
このブログで、Mongoose Web Server Library v7.14のTLSスタックに影響する10件のメモリ破壊の脆弱性の公開を発表した。この脆弱性が悪用されると、組み込み機器やIoT 、DoSなどの深刻なセキュリティリスクにつながる可能性があります。私たちの調査結果を受け、Cesanta社は速やかにMongoose v7.15ライブラリを開発し、リリースしました。このライブラリには、私たちが調査中に特定したすべての脆弱性に対するパッチが含まれています。これらの問題は深刻な影響を与えるので、Mongooseライブラリを使用しているすべての開発者と組織は、これらのセキュリティ問題から確実に保護されるように、バージョン7.15以降にアップグレードすることを強く推奨します。
