OpenSSL、最新リリースで高深刻度のDTLSメモリリークを修正

OpenSSLは9月29日、Datagram Transport Layer Security（DTLS）実装における高深刻度の脆弱性に対応するセキュリティアップデートをリリースしました。CVE-2026-84782として追跡されているこの欠陥により、攻撃者はハンドシェイクの再送中に特定の競合状態を引き起こし、ヒープメモリを漏洩させたり、サービス拒否（DoS）状態に陥らせたりする可能性があります。最近のブランチ向けには公開された修正が利用可能ですが、古いバージョンでは現在、有料のプレミアムサポートが必要となっています。

何が起きたか

この脆弱性はDTLSプロトコルに影響します。DTLSは本質的にUDPトラフィック用に適応させたTLSであり、音声やビデオ通話などのWebRTCのようなリアルタイム通信システムで一般的に使用されています。問題は、大きなハンドシェイクメッセージが断片化されて送信される際に発生します。ネットワークがメッセージの途中で送信を一時停止した場合、タイマーが以前メッセージの再送をトリガーすることがあります。ロジックエラーにより、再送操作は誤って、一時停止中の大きなメッセージのバッファ位置を使用し、再送対象メッセージの先頭へリセットされません。

この不一致により、再送パケットにはより大きなメッセージからの残りのバイトが含まれ、誤ったラベル付けが行われます。これらのバイトにはアプリケーションのヒープメモリからの未暗号化データが含まれる可能性があり、機密情報がリモートピアに露出することになります。最悪の場合、読み取り操作がマッピングされていないメモリにアクセスすると、アプリケーションがクラッシュします。SecorizonのLaurent Gaffie氏が8月17日にこの問題を報告し、Ryan Hooper氏がパッチを開発しました。OpenSSLは、攻撃者がこの条件を確実に強制できるかどうかを確認しておらず、野外でのエクスプロイトも観測されていません。

修正はOpenSSL 4.0.3、3.6.5、3.5.9、および3.4.8に含まれています。しかし、古いブランチのユーザーにとって状況はより複雑です。OpenSSL 3.0は9月7日に一般セキュリティサポートの終了期限を迎えました。その結果、バージョン3.0用の修正（3.0.23としてリリース）は、プレミアムサポート契約を持つ顧客のみが利用可能です。長年非推奨となっている1.1.1および1.0.2ブランチにも同じ制限が適用されます。

仕組み

DTLSは、大きなハンドシェイクメッセージを小さなデータグラムに断片化することで、信頼性の低いUDP接続を処理します。接続が停滞した場合、プロトコルは再送タイマーを使用して、失われた可能性のあるメッセージを再送します。バグはこのタイマーと断片化ロジックの相互作用で発生します。大きなメッセージが部分的に送信され、その後一時停止した場合、内部状態はバッファ内の現在の位置を追跡します。大きなメッセージが一時停止している間に、異なる以前のメッセージに対してタイマーが発火すると、コードは誤って再送メッセージの先頭ではなく、一時停止した位置から書き込みを続けます。

これにより、ハンドシェイクメッセージであると主張するパケットが生成されますが、実際にはヒープからの任意のデータが含まれています。ラベルが間違っているため、受信側はこのデータを有効なプロトコルコンテンツとして処理する可能性があり、情報漏洩につながります。バッファオーバーランが無効なメモリアドレスにヒットした場合、プロセスは突然終了します。この欠陥はDTLSクライアントとサーバーの両方に影響し、修正により再送時にバッファポインタが常に正しくリセットされるようになります。

主要な詳細

• CVE識別子: CVE-2026-84782、OpenSSLによってHigh深刻度、CISAによって8.2/10と評価。
• 影響を受けるプロトコル: DTLSのみ; TCP経由の標準的なTLSは影響を受けません。
• 公開修正: OpenSSL 4.0.3、3.6.5、3.5.9、および3.4.8で利用可能。
• 制限付き修正: OpenSSL 3.0.23、1.1.1zj、および1.0.2zsはプレミアムサポート顧客のみが利用可能。
• ディストリビューションの更新: Ubuntu 26.04、24.04、および22.04はパッチ済みパッケージをリリースしました。Debian 13は修正済みですが、Debian 12は9月30日時点で依然として脆弱です。
• その他の欠陥: このリリースでは、OpenSSL 4.0における中程度の深刻度のクラッシュ（CVE-2026-84783）を含む、他の13の問題も修正されています。

なぜ重要か

リアルタイム通信ツールを開発している開発者にとって、この脆弱性はユーザーのプライバシーとサービスの可用性に対する直接的なリスクをもたらします。ヒープメモリリークにより、セッションキー、個人データ、または内部アプリケーションの状態が露出する可能性があります。DTLSはWebRTCの基盤であるため、UDP経由で音声、ビデオ、またはリアルタイムデータチャネルを使用するすべてのサービスは、OpenSSL依存関係を検証する必要があります。ワークアラウンドが存在しないという事実は、更新が唯一の緩和策であることを意味します。

OpenSSL 3.0がプレミアム限定のセキュリティ更新に移行することは、多くのLinuxディストリビューションや組み込みシステムにとって重大な変化です。OpenSSL 3.0をバンドルしているUbuntuやDebianのLong Term Support（LTS）バージョンに依存しているチームは、現在、ディストリビューションメンテナーによるバックポートに頼るか、商用サポートを購入する必要があります。これは安全なインフラストラクチャの維持における運用上の複雑さと潜在的なコストを追加し、積極的な依存関係管理の必要性を浮き彫りにしています。

あなたができること

• DTLSのためにOpenSSLを使用しているすべてのサービス、特にWebRTCゲートウェイやVoIPサーバーを特定してください。
• 最新の公開修正版（4.0.3、3.6.5、3.5.9、または3.4.8）にアップグレードしてください。
• OpenSSL 3.0を使用している場合は、ディストリビューション固有のパッチ（例：Ubuntuのlibssl3t64更新）を適用し、必要に応じて再起動してください。
• 将来の公開セキュリティ更新を確保するために、OpenSSL 3.0から現在サポートされているブランチ（3.5や4.0など）への移行を検討してください。
• パッチがリリースされるまで依然として脆弱であるDebian 12システムを注意深く監視してください。
• 試みられた悪用を示唆する可能性のある異常なクラッシュやハンドシェイク失敗についてログを確認してください。