libheifに存在する重大なヒープバッファオーバーフローの脆弱性により、認証済みのWordPressユーザーが、標準のメディアライブラリから細工したHEIC画像をアップロードするだけで、リモートコード実行（RCE）を達成できる恐れがあります。
Hacking& Cracking
この脆弱性は「GHSA-x8r2-mggj-j6wr」として管理されており、libheifの非圧縮画像（unci）デコーダーに影響します。libheif 1.23.3で修正されました。
影響を受けるWordPress環境では、アップロードされたHEICファイルがWordPressからPHPのImagick拡張、ImageMagickを経由してlibheifに渡されます。脆弱な画像解析は、この過程でPHP-FPMのワーカープロセス内で実行されます。
問題は、libheifのミックスインターリーブ方式のYCbCrデコード処理にあります。悪意ある画像は、Cb（色差）コンポーネントを16ビット、Crコンポーネントを8ビットと宣言できます。
libheifはCrの画像プレーンを1サンプルあたり1バイトで確保します。ところが、脆弱なコードは両方の色差チャネルを書き込む際に、Cbコンポーネントの2バイト幅を使用します。
その結果、Crの確保領域を超える範囲外書き込みがファイルの内容によって制御可能となり、ヒープ破壊が起こります。
Fortbridgeの研究者らは、このメモリ破壊を連鎖させることで、認証済みのリモートコード実行が可能になることを実証しました。対象は、きわめて限定された2つのWordPress環境です。1つはUbuntu 26.04、WordPress 7.1.1、PHP-FPM 8.5.4、ImageMagick 7.1.2.18、libheif 1.21.2の環境、もう1つはDebian 13、WordPress 7.0、PHP-FPM 8.4.24、ImageMagick 7.1.1.43、libheif 1.19.8の環境です。
概念実証（PoC）では、WordPressのAuthor（投稿者）権限のユーザーが悪意あるHEICコンテンツをアップロードした後、PHP-FPMのアカウントであるwww-dataとしてコマンドが実行されました。
この攻撃には、upload_files権限を持つ認証済みのWordPressアカウントが必要です。通常はAuthor以上のロールが該当します。
ただし、ゲストによるアップロードを許可している環境や、プラグインを通じて同じ画像処理経路を公開している環境では、設定次第でリスクが広がる可能性があります。
このエクスプロイトチェーンは、1回の悪意あるアップロードだけで成立するわけではありません。まず、特別に作成したHEIC画像を使い、WordPressが生成する派生画像からアドレス情報をリークさせます。
WordPressがアップロード画像を処理してJPEGに再圧縮した後、その派生画像のピクセルを通じて、メモリの内容が露出する場合があります。
Fortbridgeによると、この情報漏えいの部分は、別のlibheifの脆弱性「GHSA-2jg2-4ch7-h545」を土台にしています。この脆弱性は、派生画像とピクセルプレーンの処理における範囲外読み取りおよび書き込みに関するものです。
この問題はバージョン1.23.1までが影響を受け、libheif 1.23.2で修正されています。
エクスプロイトは、返されたピクセルからリークした値を復元し、libc、libheif、ImageMagickの各コンポーネントなど、読み込まれているモジュールのアドレスを特定します。
続いて、標的サーバーのOS、ライブラリのバージョン、アロケータの挙動、オブジェクトのレイアウトに合致するプロファイルを選択します。そのうえで、ASLRを考慮したunciペイロードを生成します。
このため、公開されたエクスプロイトチェーンは、あらゆる環境で確実に動作するものではなく、環境への依存度が非常に高いと言えます。
それでも今回の研究は、画像デコーダーにおける制御可能なヒープ破壊が、単なるサービス拒否（DoS）にとどまらず、実際のWordPress/PHP-FPMの処理フローでコード実行に結び付き得ることを示しました。
ラボでのテストでは、Fortbridgeは、新規に起動したUbuntuのPHP-FPM親プロセスで8回中6回、Debianでは24回中22回、コマンド実行に成功したと報告しています。
Fortbridgeの調査結果は、画像のアップロードやサムネイル生成といった一見ありふれたWeb機能が、アプリケーションをより深いネイティブコードの攻撃面にさらし得ることを示しています。
libheifの脆弱性
研究者らは、PHP-FPMのワーカースケジューリング手法を利用しました。これにより、メモリの開示、ヒープの調整、最終的なトリガーのためにワーカーを1つ確保しています。
この結果は重要です。画像処理スタックには、一般的なWebアプリケーションの脅威モデルの外にあるネイティブライブラリが含まれていることが多いためです。
強力なパスワード、プラグインのパッチ適用、ロール管理といった従来のWordPressの堅牢化策だけでは、攻撃者が制御するメディアを処理する脆弱なImageMagickやlibheifの依存関係を保護できません。
libheifのメンテナーは、このミックスインターリーブの問題を重大と分類し、すべてのユーザーにアップグレードを呼びかけています。
バージョン1.23.3はバージョン1.23.2とAPI・ABI互換です。影響を受ける環境では、そのまま置き換えられます。
管理者は、libheifをバージョン1.23.3以降にアップグレードするか、上流の修正を取り込んだベンダー提供の最新のセキュリティパッケージを適用してください。
Cybersecurity news
Debianは、GHSA-x8r2-mggj-j6wr を含むlibheifの複数の脆弱性に対処するstable向けセキュリティアップデートを、バージョン1.23.4-1~deb13u1で公開しました。
パッチ適用後は、PHP-FPMの再起動も必要です。長時間稼働しているワーカープロセスが、脆弱なライブラリをメモリ上に保持し続けている可能性があるためです。
HEICやAVIFのアップロードが不要な環境では、ネイティブデコードが行われる前の段階で、これらの形式を無効化するか拒否することを推奨します。
画像処理は、最小権限のサービスに分離してください。ネットワークアクセスを制限し、アプリケーションのシークレットを持たせず、書き込み可能なディレクトリも厳格に管理します。
防御側は、PHP-FPMワーカーの繰り返しの異常終了、画像アップロード時のHTTP 503エラー、そしてunci、iden、crop、overlay、gridの画像リレーションを含む不審なHEICファイルを調査する必要があります。
クラッシュが発生しただけでは悪用の証拠にはなりません。それでも、画像処理中に障害が繰り返し発生する場合は、潜在的なセキュリティイベントとして扱うべきです。
MTTRを21分短縮し、被害が出る前にサイバー脅威を阻止。ANYRUNのサンドボックスをSOCに統合
翻訳元: https://gbhackers.com/libheif-vulnerability/
