HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload

「HollowByte」と呼ばれるこの脆弱性により、認証されていない攻撃者は、わずか11バイトの悪意のあるペイロードを用いて、OpenSSLサーバーに対してサービス拒否（DoS）状態を引き起こすことが可能となります。

OpenSSLチームはこの脆弱性を（識別子は割り当てられていない）黙って修正し、パッチを旧バージョンにも適用しました。

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

image

HollowByteの詳細

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

研究者らによると、TLSハンドシェイクにおいて、各メッセージには受信メッセージのサイズを宣言するための4バイトのヘッダーが含まれています。しかし、この脆弱性のあるOpenSSLのバージョンでは、ペイロードを受信してそのサイズを確認する前に、宣言された長さのメモリを割り当ててしまいます。

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

ペイロードを検証することなく、サーバーはパケットの主張を鵜呑みにし、指定されたメモリを割り当ててしまいます。「その結果、ワーカースレッドはブロックされ、決して到着することのないデータを無期限に待ち続けることになります」とOktaは説明しています。

認証されていない攻撃者は、TLS接続を開き、はるかに大きなメッセージ本体が続くことを宣言するヘッダーを含む11バイトの悪意のある入力を送信することで、HollowByteを誘発できます。

攻撃者は複数の接続で同じプロセスを繰り返すことで、比較的少量の送信データを通じてサーバーに多量のメモリを割り当てさせます。

Oktaの研究者らは、OpenSSLは接続が切断されるとバッファを解放するが、GNU Cライブラリ（glibc）はメモリを処理する方法が異なり、「中小規模の割り当てを直ちにオペレーティングシステムに返さず、再利用の可能性に備えて保持し続ける」と指摘している。

「ランダムなサイズを指定して接続の波を仕掛けることで、攻撃者はアロケーターが解放されたメモリ領域を再利用できないようにする」と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パッケージを直ちにアップグレードすること」を推奨しています。