- 履歴一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- CVE-2025-57803 へ行く。
- 1 (2025-09-01 (月) 13:49:17)
- 2 (2025-09-01 (月) 14:10:04)
- 3 (2025-09-01 (月) 17:42:57)
- 4 (2025-09-02 (火) 17:21:30)
- https://nvd.nist.gov/vuln/detail/CVE-2025-57803
Prior to versions 6.9.13-28 and 7.1.2-2 for ImageMagick's 32-bit build, a 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses bytes_per_line (stride) to a tiny value while the per-row writer still emits 3 × width bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines. This issue has been patched in versions 6.9.13-28 and 7.1.2-2.
ImageMagickの32ビットビルドのバージョン6.9.13-28および7.1.2-2より前のバージョンでは、BMPエンコーダのスキャンラインストライド計算における32ビット整数オーバーフローにより、bytes_per_line（ストライド）が極小値にまで縮小されますが、行ごとの書き込みは24bpp画像に対して依然として3 × widthのバイトを出力します。行ベースポインタは（オーバーフローした）ストライドを使用して進むため、最初の行は即座にスロットを通り過ぎ、攻撃者が制御するバイトで隣接するヒープメモリに書き込みます。これは、一般的な自動変換パイプラインにおけるヒープ破損の典型的な強力なプリミティブです。この問題は、バージョン6.9.13-28および7.1.2-2で修正されています。
.†
- CVE-2025-57803: Critical Flaw in ImageMagick Could Lead to Remote Code Execution
32bit int のオーバーフローなので、int が 64bit のマシンだと発生しないはず。ILP64 なら大丈夫？ Windows はILP64 なので駄目？
PoC が極端な横長(180000000x1)画像を入力与えて BMP 出力する例なので、縦横サイズを制限してれば大丈夫かも？