わずか11バイトでメモリを圧迫 OpenSSLを狙う新DoS攻撃、その意外な仕組み：従来対策では不十分

OpenSSLで、少量の通信でサーバのメモリを消費させる新たなDoS問題が見つかった。特徴は、TLS通信が始まる前の処理を悪用し、一般的な接続数制限だけでは十分に防げない可能性があることだ。多くのソフトウェアが利用するライブラリーで何が起きていたのか。

[＠IT]

　Oktaは2026年7月16日（現地時間）、同社のレッドチームが暗号通信ライブラリー「OpenSSL」にDoS攻撃を引き起こす脆弱（ぜいじゃく）性「HollowByte」を発見したと公表した。

　遠隔の未認証ユーザーは、わずか11バイトの細工したデータを送るだけで、サーバに最大約131KBのメモリを確保させられる。TLSハンドシェイクが始まる前の処理を悪用するため認証は不要で、接続を切断した後もメモリ使用量の増加が残る場合があるという。

一般的なDoS対策では防ぎにくい、その理由とは？

　TLSハンドシェイクでは、「ClientHello」メッセージの先頭4バイトに、後続する本文の長さが記録されている。旧版のOpenSSLは、この長さ情報を基に、本文が届く前から受信用バッファーを確保する仕様だった。

　細工した11バイトのデータを受信すると、OpenSSLはヘッダに記載されたサイズを信頼し、最大約131KBのメモリを確保する。しかしこの時点では本文はまだ届いておらず、その内容も確認されていない。本文が送信されなければ、サーバは不要なメモリを保持したまま待機し続ける。

　さらに接続終了後は、OpenSSLがメモリを解放しても、「GNU C Library」（glibc）は再利用のために領域を保持する。この状態で異なるサイズの接続を繰り返すとヒープの断片化が進み、プロセスが実際に使用する物理メモリ量は増え続ける。メモリ使用量は接続終了後もすぐには元に戻らず、プロセスの再起動が必要になる場合もある。

　Oktaのレッドチームは未修正版と修正版のOpenSSLを組み込んだ「NGINX」で検証を実施した。メモリ1GBの環境では、未修正版のサーバが約547MBのメモリを保持したままとなり、最終的にOOMキラーによって停止した。

　メモリ16GBの環境では、接続数の上限に達しない条件でも、システム全体の約25％のメモリを利用できない状態にできた。接続を長時間維持してサーバ資源を消費させる点は、HTTPリクエストを少しずつ送信して接続枠を占有するDoS攻撃の一種、スローロリスと似ている。一方、HollowByteはメモリ管理の仕組みも悪用するため、接続終了後もメモリ使用量が元に戻りにくい点が特徴だ。

　影響を受ける可能性があるのは、「Apache HTTP Server」やNGINXなどのWebサーバ、「Node.js」「Python」「Ruby」「PHP」などのランタイム、「MySQL」「PostgreSQL」など、OpenSSLを利用するソフトウェアだ。

　修正はOpenSSL 4.0.1の他、3.6.3、3.5.7、3.4.6、3.0.21にもバックポートされた。OpenSSLはこの問題をCVE付きの脆弱性ではなく、堅牢（けんろう）性を高める修正として扱っている。Okta Red Teamは、利用中のディストリビューションが提供するOpenSSLパッケージへ速やかに更新するよう呼び掛けている。