OpenSSL の DoS 脆弱性 HollowByte CVE-N/A が FIX：11 バイトのペイロードでメモリ枯渇

OpenSSL “HollowByte” Vulnerability Lets Hackers Crash Servers With Just 11 Bytes

2026/07/17 CyberSecurityNews — HollowByte と呼ばれる OpenSSL で新たに公表された脆弱性は、TLS ハンドシェイク中に OpenSSL がメモリを事前割り当てる仕組みの悪用を許すものである。Okta Red Team により発見された、この脆弱性を悪用するリモートの攻撃者は、認証処理が行われる前にサーバに対して巨大なメモリ領域を確保させる。具体的には、わずか 11 バイトの悪意あるペイロードを用いて、サービス拒否 (DoS) 攻撃が引き起こされる。

OpenSSL の脆弱性 HollowByte

すべての TLS ハンドシェイクは、受信メッセージ本文のサイズを宣言する、4 バイトのヘッダーを含むレコードでラップされた ClientHello メッセージから始まる。しかし、古い OpenSSL バージョンでは、ライブラリは実際のデータが到着する前に、攻撃者が宣言した長さに基づいて受信バッファが割り当てられるため、細工された 11 バイトのペイロードが到着したときに、TLS ステート・マシンはヘッダーを読み取り、以下の未検証の割り当てチェーンを引き起こす。

Read Header → grow_init_buf() → OPENSSL_clear_realloc() → malloc(attacker_size)

この段階では検証が行われないため、単一の悪意のパケットだけで、攻撃者が宣言したサイズのみに基づき、malloc() に最大 131 KB のメモリを割り当てさせることが可能になる。その結果として、ワーカー・スレッドは到着することのないデータを待ち続け、無期限にブロックされる。

Slowloris のような従来型の接続枯渇の攻撃は、接続を開いた状態で維持させ、サーバ・スレッドのリソースを枯渇させるが、HollowByte においては、glibc が解放済みメモリを管理する仕組みに起因する、メモリ断片化の問題が組み合わされるため、さらに状況が悪化する。

攻撃用の接続が切断されると、OpenSSL はバッファを解放するが、glibc は小規模から中規模の割り当て領域を直ちにオペレーティング・システムへ返却せず、再利用に備えて保持し続ける。

したがって攻撃者は、ランダム化された宣言サイズを持つ接続を大量に発生させることで、これらの解放済み領域のアロケータによる再利用を阻止できる。その結果として、攻撃者が接続を切断した後も、サーバの Resident Set Size (RSS) は恒久的に増加し続ける。唯一の対処法は、プロセス自体を終了することである。

NGINX 上で動作するパッチ未適用の OpenSSL インスタンスに対して、Okta Red Team が実施したテストでは、深刻な影響が確認された。

1 GB RAM 環境では、547 MB の断片化したメモリ領域が蓄積した後、サーバは OOM Killer により強制終了された。また、16 GB RAM 環境では、攻撃によりシステム全体のメモリの 25% が占有されたが、接続数は標準的な上限を下回っていた。つまり、一般的な接続制限による防御では、この攻撃を阻止できないことが示された。

OpenSSL はインターネット・インフラの広範な領域を支えているため、この脆弱性の影響が及ぶ範囲は、Apache／NGINX などの Web サーバや、Node.js／Python／Ruby／PHP などの言語ランタイム、MySQL／PostgreSQL などのデータベースにまで至る。

すでに OpenSSL は、プルリクエスト #30792／#30793／#30794 で導入された段階的なバッファ拡張方式への移行により、この問題を解決している。ヘッダーで宣言されたサイズを信頼するのではなく、実際にネットワーク経由でデータが到着した場合にのみ、バッファを拡張する仕組みへ変更されたことで、実体のないサイズ宣言がサーバに負荷を与えることが無くなった。

この修正は OpenSSL v4.0.1 に秘密裏に組み込まれ、3.6.3／3.5.7／3.4.6／3.0.21 にもバックポートされたが、OpenSSL はセキュリティ強化の一環として扱い、この問題を正式な CVE アドバイザリとして公開しなかった。これは、DoS クラスの問題が注目度の高い CVE の割り当てなしに修正される、最近の OpenSSL の開示で見られる傾向である。

HollowByte は CVE が割り当てられず、サイレント・パッチとして扱われたため、多くの組織では標準的な脆弱性スキャンで検出できない可能性がある。前述のとおり、OpenSSL は Web サーバ／言語ランタイム／データベースで広く利用されていることから、セキュリティ・チームは CVE の有無にかかわらず、この修正を優先的に適用すべきである。

推奨される対策

• OpenSSL 4.0.1 へと直ちにアップグレードする。または、該当するバックポート版 3.6.3／3.5.7／3.4.6／3.0.21 へアップグレードする。
• OS レベルのパッチだけでは、バンドルされた OpenSSL は更新されないため、Node.js／Python／Ruby／PHP などの言語ランタイムに組み込まれている、OpenSSL のバージョンを監査する。
• TLS 終端サーバにおいて RSS (Resident Set Size) メモリの推移を監視し、断片化攻撃に起因する原因不明の緩やかなメモリ増加の有無を確認する。

今回の問題は、TLS ハンドシェイクにおいて OpenSSL がデータ受信前にヘッダーで宣言されたデータ長を信頼してメモリを事前割り当てしてしまう点に起因しています。実際のデータ到着を確認せずに、未検証の状態でメモリ領域が確保されるため、悪意のデータ長を宣言されると無駄な領域が生成されます。さらに、切断後に OpenSSL が解放したメモリを glibc が保持し続ける仕組みと組み合わさることで、深刻なメモリ断片化が発生し、最終的に OOM Killer によるプロセスの強制終了を引き起こします。ご利用のチームは、ご注意ください。よろしければ、OpenSSL での検索結果も、ご参照ください。