本文へスキップ
MameTechNews
フロントエンド

Nuxt Image、細工画像1枚でサーバーのメモリを壊せる欠陥を修正

## POINTS

  • 認証のない/_ipxでも、画像の出所を攻撃者が操作できないサイトは影響を受けない。
  • 2.2.1は一般的なWeb画像以外を復号前に403にする。TIFFは許可リストが要る。
  • ipxはoptional dependencyなので、更新後にnpm ls ipxで解決された版を確認する。

何が起きたか

Nuxtは10月30日、画像モジュール@nuxt/imageの2.2.1と1.11.2をセキュリティリリースとして公開した。依存するipxが、複数ページ画像の復号で整数オーバーフローを起こし、細工した画像を認証なしの1リクエストで渡すと、サーバープロセスのメモリが壊れる。Nuxt側のアドバイザリはGHSA-p5vf-pjf5-ggj3、ipx側はGHSA-qf89-6xm4-66wmだ。攻撃者が画像の出所を一切操作できないサイトは影響を受けない。

2.xはipx ^4.1.0、1.xはipx ^2.1.2を要求する。修正版は大きすぎる複数ページ画像を復号の前に400で拒む。ipxはoptional dependencyなので、上げたあとにnpm ls ipxで、解決された版が修正版かを確認する。

なぜ今重要か

/_ipxはNuxt Imageの既定の変換ルートで、画像の出所を外部から指定できるアプリでは、認証なしのリクエストが復号処理に届く。2.2.1では入力形式も変わり、JPEG、PNG、WebP、GIF、SVG、AVIF、HEIC以外は復号前に403になる。TIFFなどを変換している場合は、image.ipx.allowedInputFormatsへ明示する。信頼できない出所には、他形式のデコーダをプロセス全体で止めるimage.ipx.restrictDecodersもある。1.11.2は形式の制限を足さず、緩和はipxの更新だけだ。

エンジニアが取ること

利用者がURLやファイルを渡せる画像変換を本番で使っているなら、2.2.1または1.11.2へ上げる。ロックファイル上のipxが、2.xなら4.1.0以上、1.xなら2.1.2以上になっているかを見る。形式を絞ったことで、これまで通っていたTIFFなどの変換が403になる。許可が必要な形式だけを設定へ戻す。