Ruby on Rails の画像アップロードに重大な欠陥（GHSA-f3w6-w445-fwh9）— 画像を1枚送るだけでサーバーの秘密の鍵が抜かれる

この記事は 11月4日時点の情報です。

何が原因か

Rails の Active Storage は、利用者がアップロードした画像を受け取ると、サイズや向きを調べたり、縮小版を作ったりするために、ImageMagick という画像処理のソフトに画像を渡します。

ImageMagick は、とても多くのファイル形式を扱える便利なソフトです。ただ、形式の中には、画像の中に「別のファイルを読め」「ここにファイルを書け」といった指示を書けるものがあります。本来は、そうした危ない形式を使わせない設定（ポリシー）で守るのが決まりです。

ところが Active Storage は、どの形式を使ってよいかを何も制限しないまま、アップロードされたファイルを ImageMagick に渡していました。しかもこの処理は、ファイルを添付した瞬間に自動で動きます。

項目	内容
対象	Rails の Active Storage（8.1.4.1 / 8.0.5.2 より前）
深刻度	CVSS 9.8（緊急）
攻撃の条件	利用者が画像などをアップロードできること。ログインの要否はサービスによる
できてしまうこと	サーバーのファイルの書き込み、保存先がサーバーのディスクならファイルの読み出しも
見つけた人	ryotak 氏（HackerOne 経由で報告）

対象になる3つの条件

次の3つすべてに当てはまると、対象になります。

1. 画像の処理に ImageMagick（mini_magick）を使っている（Rails 6.1 以前の初期設定で作ったアプリは、これが標準）
2. サーバーの ImageMagick の設定で、危ない形式を止めていない（Debian や Ubuntu の標準の設定では止まっていません）
3. 外部の利用者がファイルをアップロードできる

何が起きたか

• 11月4日：Rails の開発チームが、修正版 8.1.4.1 / 8.0.5.2 と注意喚起を公開
• 同じ日に、動画のプレビューを作る処理にも似た欠陥（GHSA-v924-7rp8-4mxh、重要）が公表されました
• 同じ修正版では、ほかにもたくさんの欠陥がまとめて直っています

開発チームは「報告された攻撃の道筋は1つだが、それだけだとは考えていない」としています。悪用の報告や、攻撃コードの公開は、11月4日時点ではありません。CVE 番号は、Rails の注意喚起にはまだ書かれていません。

どんな問題があるか

• サーバーのファイルを書き換えられる：プログラムや設定を書き換えられると、サービスを乗っ取られるおそれがあります
• 秘密の鍵や接続情報が漏れる：Rails の秘密の鍵、データベースやクラウドの保存場所のパスワードなど、サーバーの中の大事な情報が読み出されるおそれがあります
• つながっているほかのシステムにも広がる：漏れた接続情報で、データベースや外部のサービスまで入られることがあります
• アップロードの機能はどこにでもある：プロフィール画像、商品の写真、書類の添付など、ふつうの機能が入口になります

実は「2回目」— 2016年の ImageTragick

ImageMagick の危ない形式が狙われたのは、今回が初めてではありません。2016年には、細工した画像で ImageMagick にサーバーの命令を実行させる欠陥（CVE-2016-3714、通称「ImageTragick」）が見つかり、世界中の画像アップロード機能が一斉に見直されました。そのとき広まった守り方が、「危ない形式は設定で止めておく」ことです。今回は、Rails の Active Storage がその守りを自分では入れていなかったことが問題になりました。

自社のサービスが Active Storage を使っているか見分けるには

制作会社やエンジニアに、次の点を見てもらうとすぐにわかります。

• Gemfile.lock に activestorage が入っているか（Rails の標準で入っていることが多い）
• モデルに has_one_attached や has_many_attached があるか（ファイルを添付する機能を使っている印）
• config.active_storage.variant_processor の設定：:mini_magick なら ImageMagick を使っています。:vips なら今回の主な道筋からは外れますが、動画のプレビューの欠陥（GHSA-v924-7rp8-4mxh）は別に確認が必要です
• ファイルの保存先：サーバーのディスク（Disk）か、クラウドの保存場所（Amazon S3 など）か。ディスクの場合は、読み出しの被害まで考える必要があります

臨時の対処（すぐ更新できないとき）

Rails の開発チームは、次の回避策を案内しています。

1. ImageMagick の設定（ポリシー）で、危ない形式を止める
   修正版に入っている設定ファイル（policy.xml）を、サーバーの ImageMagick の設定にコピーします。最低でも、MSL という形式と、PDF・PostScript などを扱う部分（Ghostscript）を止めます。PDF の縮小版を作っている場合は、必要なものだけ許可し直します。
2. アップロードできる人やファイルの種類を絞る
   受け付ける形式を画像（JPEG・PNG など）に限り、だれでも投稿できる入口を一時的に止めることも検討します。

正しい対処

1. Rails（activestorage）を修正版に更新する
   8.1 系は 8.1.4.1、8.0 系は 8.0.5.2 以降。修正版は mini_magick 5.1 以降が必要で、古いままだと起動時にエラーになります。
2. 保存先がサーバーのディスクなら、秘密の鍵をすべて入れ替える
   Rails の secret_key_base、マスターキー、credentials の中身、データベースや外部サービスのパスワードを作り直し、古いものは使えなくします。
3. Rails 7.2 以前は、移行を計画する
   今回の修正版は 8.0 系・8.1 系向けです。8.0 系もまもなくサポートが終わる見込みです。
4. 独自の画像処理の設定をしている場合は、サーバー側の設定も直す
   mini_magick の動かし方を独自に変えているアプリは、修正版の設定が効かないことがあります。

まとめ

• 原因は、アップロードされたファイルを、危ない形式を止めないまま ImageMagick に渡していたこと
• 画像1枚でファイルの書き換え・読み出しができ、秘密の鍵まで抜かれるおそれ
• つなぎは ImageMagick の設定で危ない形式を止めること、正しい対処は 8.1.4.1 / 8.0.5.2 への更新
• 保存先がサーバーのディスクなら、秘密の鍵をすべて入れ替える

無料メルマガ・月2〜4回 セキュリティ速報と
最新情報をメールで 登録する