OpenSSLがDTLSのメモリリークを修正:更新が必要なバージョンは?

OpenSSLは、ヒープメモリの漏えいやアプリケーションのクラッシュにつながる重大度の高いDTLSの欠陥を修正した。修正版と、セキュリティチームが取るべき次の対応を確認しよう。

執筆者
Michelle Lojo
Michelle Lojo
Sep 30, 2026
4 minute read
eSecurity Planet のコンテンツおよび製品のおすすめは、編集上の独立性を保っています。パートナーへのリンクをクリックすると、当社が報酬を得る場合があります。 詳細を見る

OpenSSLのDTLSハンドシェイク処理にある欠陥により、アプリケーションのメモリの断片が接続先に送信される可能性がある。

OpenSSLは9月29日、CVE-2026-84782として追跡される重大度の高い脆弱性を公開し、修正した。同社の セキュリティアドバイザリによると、このバグによってヒープメモリが平文のハンドシェイクデータとして露出したり、影響を受けたプロセスがクラッシュしてサービス拒否が発生したりする可能性がある。

セキュリティチームにとって最初の問いは、通常はUDP上でデータグラム通信を保護するプロトコル、Datagram Transport Layer Security(DTLS)を使用するアプリケーションがどれかということだ。今回の欠陥は、別のハンドシェイク書き込みが一時停止している間にOpenSSLがハンドシェイクメッセージを再送すると発生するため、各アプリケーションがDTLSをどのように利用しているかを確認する必要がある。

DTLSの欠陥がメモリを露出させる仕組み

この問題は、基盤となるトランスポートが一時的にこれ以上のデータを受け付けられず、ハンドシェイクメッセージが一部しか書き込まれない場合に発生する。その書き込みが停止している間に再送タイマーが作動すると、OpenSSLは共有バッファー内の誤った位置を使って、以前のメッセージを再送する可能性がある。

この古い位置情報により、再送データに意図しないバイト列が含まれ、確保済みバッファーの範囲外まで読み取る可能性がある。そうしたバイト列は暗号化されないまま接続先に届くことがあり、マッピングされていないメモリ領域を読み取った場合は、代わりにプロセスがクラッシュする可能性がある。

アドバイザリでは、停止中の書き込みを再開するために必要な管理情報が再送によって上書きされる、別の障害についても説明している。書き込みを再開すると、デバッグビルドではプロセスが異常終了する可能性がある。今回のパッチは再送位置を修正し、ハンドシェイクの書き込みが停止している間は再送を遅延させる。

OpenSSLは1月にも リモートコード実行を可能にする脆弱性に対処した。今回のDTLSの欠陥について文書化されている影響は情報漏えいとサービス拒否であり、アドバイザリはリモートコード実行を結果として挙げていない。

更新が必要なOpenSSLのバージョンは?

OpenSSLのアドバイザリには、影響を受ける各ブランチについて、次のアップグレード先が記載されている。

OpenSSLブランチ

修正版

4.0

4.0.3

3.6

3.6.5

3.5

3.5.9

3.4

3.4.8

3.0

3.0.23

1.1.1

1.1.1zj

1.0.2

1.0.2zs

アドバイザリによると、3.0、1.1.1、1.0.2向けの修正はプレミアムサポートの対象となる。

ディストリビューションのパッケージを利用している組織は、アップストリームのバージョン番号だけでパッチ適用状況を判断せず、ディストリビューターのセキュリティ通知を確認すべきだ。例えばUbuntuでは、Ubuntu 24.04 LTS向けの3.0.13-0ubuntu3.16や、Ubuntu 22.04 LTS向けの3.0.2-0ubuntu1.30などのパッケージに修正が含まれると案内している。

セキュリティチームが今すべきこと

実務的な対応は、影響を受けるOpenSSLのバージョンを使用しているアプリケーションを特定し、それらがDTLSを使用しているかを判断することから始まる。供給元に影響の有無や利用可能な更新を問い合わせる際は、ベンダーが管理する製品や、ライブラリのコピーを組み込んだアプリケーションも対象に含めるべきだ。

チームは 脆弱性管理ツールを使って検出と修正状況の追跡を支援し、その後、開発者やベンダーにアプリケーション固有の影響を確認できる。ライブラリでの検出結果は調査の出発点となる。

適切なアップストリーム、ディストリビューション、またはベンダーの更新を適用し、影響を受けるサービスをテストして、デプロイに成功したことを確認する。こうした確認は、インベントリー、優先順位付け、テスト、更新後の検証を網羅する、再現可能な パッチ管理プロセスに組み込む必要がある。

防御側にとっての要点は明確だ。影響を受けるDTLSコードがどこで使われているかを把握し、更新ごとに担当者を割り当て、アプリケーションが修正版ライブラリを実行していることを確認する。

詳しく読む: 重大なGitLab GraphQLの欠陥により、公開リポジトリが削除や改ざんの被害を受ける可能性について解説します。

Advertisement


Michelle Lojo

Michelle Lojo is an editor with eight years of experience in journalism. She covers the developments, companies, and emerging trends shaping enterprise technology. Her editorial work focuses on clear, well-researched reporting that helps business and IT leaders understand a rapidly changing technology landscape.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

TechnologyAdvice が所有・運営しています。 © 2026 TechnologyAdvice. 無断転載を禁じます

広告主に関する開示:このサイトに掲載されている製品の一部は、TechnologyAdvice が報酬を受け取っている企業のものです。この報酬は、製品がこのサイトのどこにどのように表示されるか(表示される順序など)に影響する場合があります。TechnologyAdvice は、市場で入手可能なすべての企業やすべての種類の製品を掲載しているわけではありません。