libheifに存在する重大な脆弱性を悪用されると、悪意あるHEICファイルをアップロードされた際にWordPressの画像処理中にメモリが破壊され、環境条件が厳密に一致するサーバーではリモートコード実行（RCE）に至る恐れがあります。問題は非圧縮画像デコーダーunciに存在し、libheifバージョン1.23.3で修正されました。
GHSA-x8r2-mggj-j6wrとして追跡されているこの脆弱性は、libheifによるmixed-interleave形式のYCbCr画像の処理に起因します。攻撃者が細工したHEICファイルでは、一方のクロマチャネルを16ビット、もう一方を8ビットと宣言できます。
libheifは各チャネルの実際のサイズに基づいてメモリを割り当てます。ところが、脆弱なデコーダーは両方のチャネルへの書き込みに、16ビットチャネルの幅を使用します。
その結果、サイズの小さい8ビットのCrプレーンの範囲を超えてデータが書き込まれ、攻撃者が制御可能なヒープバッファオーバーフローが発生します。
WordPressの環境では、通常はAuthor（投稿者）以上の、ファイルのアップロード権限を持つ認証済みユーザーが、メディアライブラリ経由で悪意ある画像を送信できます。
WordPressがサムネイルなどの派生画像を生成する際、この画像はPHP Imagick、ImageMagick、libheifの順に処理される場合があります。
Webアプリケーションの側から見ると、アップロード自体は通常の操作に見えるため、リスクは大きいといえます。脆弱な処理はサーバー側のネイティブ画像処理スタックの深部で実行されるため、PHPやWordPressの通常のセキュリティ対策では防げません。
Fortbridgeの研究者らは、次のようなエクスプロイトチェーンを説明しています。まず、特別に細工した情報漏えい用の画像をアップロードし、続いてWordPressが生成したJPEGの派生画像を取得します。
返ってきた画像のピクセルから、処理ワーカーのメモリデータを読み取れる場合があります。これにはアドレス空間配置のランダム化（ASLR）を回避するために必要なアドレスも含まれます。
研究者らは、Ubuntu 26.04とDebian 13の2つの特定のラボ環境で、PHP-FPMのwww-dataユーザーとしてidコマンドの実行に成功したと主張しています。いずれも、特定のビルドのWordPress、PHP-FPM、ImageMagick、libheif、glibcを使用した環境です。
ただし、この結果をすべてのWordPressサーバーに通用する汎用的な攻撃と解釈すべきではありません。
アドバイザリーでは、悪用の成否が環境の詳細に大きく左右されることが確認されています。攻撃者には、互換性のあるライブラリのバージョン、CPUアーキテクチャ、C++オブジェクトのレイアウト、ヒープの挙動、ワーカーの継続性、実行時アドレスが必要です。
Wordfenceの研究者Alex Thomas氏も、PHP Imagick、ImageMagick、libheifを使用した特定のWordPress環境1件で、ファイルの漏えいとコード実行の影響を独自に実証しました。
アドバイザリーは、これがlibheifを使用するすべての環境で通用する、移植可能なRCEや汎用的なRCEを立証するものではないと注意を促しています。
別のlibheifアドバイザリーであるGHSA-2jg2-4ch7-h545は、派生画像とピクセルプレーンの処理に関する脆弱性に対処したものです。影響を受けるのは1.23.1までのバージョンで、1.23.2で修正されました。一方、今回のmixed-interleaveのバグは1.23.2でも悪用可能で、修正には1.23.3が必要だとFortbridgeは述べています。
組織はlibheifを1.23.3、または修正を含むベンダーパッケージにアップグレードする必要があります。あわせて、不要な環境ではHEICとAVIFのアップロードを無効化し、メディア処理を最小権限のコンテナーに隔離し、アップロードディレクトリでのスクリプト実行をブロックすることが推奨されます。また、画像のアップロード後にPHP-FPMワーカーのクラッシュやHTTP 503応答が繰り返し発生していないか調査してください。
ANY.RUNを導入する16,000以上のSOCチームに加わり、脅威調査を効率化して手作業を削減しましょう。チームでの利用を検討する
翻訳元: https://cyberpress.org/wordpress-heic-uploads-enable-rce/
