HollowByte、わずか11バイトのペイロードでOpenSSLサーバーのメモリを肥大化させるDDoS脆弱性

「HollowByte」と名付けられた脆弱性により、認証を経ていない攻撃者がわずか11バイトの悪意あるペイロードを送信するだけで、OpenSSLサーバーにサービス拒否(DoS)状態を引き起こせることが判明しました。

OpenSSLチームはこの脆弱性(識別子は付与されていません)をひっそりと修正し、パッチを旧バージョンにもバックポートしています。

OpenSSLはインターネット上の安全な通信を支える基盤的なソフトウェアであるため、各組織は修正済みバージョンのライブラリへの切り替えを優先すべきです。

HollowByteの詳細

Oktaのレッドチームは今週公開したアドバイザリで、HollowByte DoS脆弱性の仕組みと、実際の環境における影響について解説しています。

研究者らによると、TLSハンドシェイクでは各メッセージの先頭に4バイトのヘッダーが付き、そこで受信予定メッセージのサイズが宣言されます。しかし脆弱性の影響を受けるバージョンのOpenSSLは、実際のペイロードを受信してそのサイズを検証する前に、宣言された長さ分のメモリを確保してしまいます。

すべてのTLSハンドシェイクメッセージは4バイトのハンドシェイクヘッダーで始まり、その中の3バイトの長さフィールドが、続くハンドシェイクデータのサイズを示します。

ペイロードを検証しないまま、サーバーはパケットの申告内容をそのまま信用し、示された分のメモリを確保してしまいます。「その結果、ワーカースレッドは、決して届くことのないデータを待ち続けたまま無期限にブロックされる」とOktaは説明しています。

認証を経ていない攻撃者は、TLS接続を開始し、はるかに大きなメッセージ本体が後続すると宣言するヘッダーを含む11バイトの悪意あるデータを送信するだけで、HollowByteを引き起こせます。

攻撃者が複数のコネクションにわたって同じ手順を繰り返すと、比較的少量のデータ送信だけでサーバー側に大量のメモリを確保させることができてしまいます。

Oktaの研究者は、OpenSSL自体はコネクションが切断されるとバッファを解放する一方、GNU Cライブラリ(glibc)のメモリ管理方式は異なっており、「小〜中規模のメモリ割り当てを直ちにOS側へ返却せず、再利用に備えて保持し続ける」と指摘しています。

「攻撃者はランダムな申告サイズを伴う接続を波状に仕掛けることで、アロケータが解放済みチャンクを再利用するのを妨げる」とOktaは述べています。

「ヒープは激しく断片化し、サーバーの常駐セットサイズ(RSS)は上昇し続けます。攻撃者が接続を切断した後も、サーバーは肥大化した状態のまま元に戻りません」

確保された領域を完全に解放する唯一の方法は、プロセスを再起動することです。

影響と修正

オープンソースのOpenSSLライブラリは、NGINXやApacheといった主要なWebサーバー、各種言語ランタイム(Node.js、Python、Ruby、PHPなど)、データベース(MySQL、PostgreSQL)に組み込まれています。また、TLS暗号化や証明書処理のため、ほとんどのLinuxディストリビューションにプリインストールされています。

Oktaが行ったNGINXでのテストでは、リソースの限られた環境ではHollowByteによって容易にメモリが枯渇する一方、より高スペックなサーバーでも攻撃帯域幅がセキュリティのアラート閾値を下回ったまま、最大25%のメモリが失われることが示されました。

DoSの脆弱性は、データ窃取やコード実行を可能にする脆弱性と比べれば深刻度は低いとみなされがちですが、業務の停止や評判の毀損につながる可能性があります。

このHollowByte DoS問題はOpenSSL 4.0.1で修正され、バージョン3.6.3、3.5.7、3.4.6、3.0.21にもバックポートされました。修正後のバージョンでは、ヘッダーの申告内容を鵜呑みにせず、実際にデータが届いた時点でのみバッファを拡張するようになっています。

今回の対応は「セキュリティ脆弱性」ではなく「堅牢化のための修正」として扱われていますが、Oktaは「お使いのディストリビューションのOpenSSLパッケージを直ちにアップグレードする」よう推奨しています。