Active Storageに任意ファイル読み書きの脆弱性、修正版あり
ImageMagickで添付画像を処理するRailsアプリで、未認証の利用者がアップロードしたファイルから、サーバー上のファイルの書き込みや読み取りを許す脆弱性が公表されました。8.1.4.1か8.0.5.2へ更新し、Disk保存なら秘密情報も入れ替えます。
急ぎ度: 至急
CVSS v3は9.8で、未認証のネットワーク経由で悪用でき、修正版も出ているため、条件に当てはまるアプリは更新を急ぐ段階です。
関係があるか
RailsのActive StorageでImageMagickを使い、外部の利用者からのアップロードを受け付けているアプリが対象です。次の3条件をすべて満たすと影響を受けます。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Rails（activestorage）8.1系 | 8.1以上、8.1.4.1未満 | 8.1.4.1 |
| Rails（activestorage）8.0系以前 | 8.0.5.2未満 | 8.0.5.2（修正版として挙がっているのは8.0系と8.1系のみ） |
確かめ方
- 11つ目の条件は、Active Storageの画像処理にImageMagickを使っていることです。
config.active_storage.variant_processorが:mini_magickかを確認します。config.load_defaultsが6.1以前のアプリでは、これが既定値です。grep -rn "variant_processor" config/で設定を探せます。 - 22つ目の条件は、ImageMagickのセキュリティポリシーが、関係するcoderを拒否していないことです。DebianとUbuntuのパッケージが入れるポリシーは拒否しません。
magick -list policy（ImageMagick 6系ではconvert -list policy）で、MSLやgsが拒否されているかを見ます。 - 33つ目の条件は、信頼できない利用者からのファイルアップロードを受け付けていることです。会員登録やプロフィール画像など、外部に開いたアップロード機能がないかを洗い出します。
- 4使っている版は
bundle list | grep -E "activestorage|mini_magick"で確認します。
何が起きたか
ImageMagickで添付画像を処理するRailsアプリで、サーバー上の任意のファイルが書き込まれ、保存先がDiskサービスならアプリが読めるファイルも読み出される脆弱性です。読み出せるファイルには、通常secret_key_baseや外部システムの認証情報が含まれます。これらを足がかりに、リモートコード実行や、つながっている他システムへの横展開へ進む恐れがあります。
ImageMagickは、渡されたファイルの中身から処理に使うcoderを選びます。coderの中には、画像そのものではなく、画像の中に書かれた別のファイルを操作するものがあります。Active Storageはこのcoderを一つも制限していませんでした。しかもファイルを添付した時点でImageMagickの解析が走ります。CWEはCWE-1188です。
報告された攻撃経路は一つですが、ほかにも存在しうるとRailsは説明しています。公表直後で、悪用の状況を示す記載はありません。ただ、条件に当てはまるアプリでは、攻撃の手口が広まる前に更新を済ませておきたい脆弱性だと筆者は考えています。
攻撃の流れ
-
1
細工した画像を送る
攻撃者がアップロード機能から、細工したファイルをアプリに渡します。
-
2
添付時に解析が動く
ファイルを添付した時点でImageMagickの解析が走り、制限のないcoderが呼び出されます。
-
3
ファイルの書き込みと読み取り
サーバー上に任意のファイルが書き込まれ、Disk保存ならアプリが読めるファイルも読み出されます。
-
4
秘密情報の流出
secret_key_baseや外部システムの認証情報が漏れ、コード実行や他システムへの横展開につながります。
どう悪用されるか
ログインは不要で、ネットワーク経由で攻撃できます。利用者の操作も要りません。攻撃の複雑さは低いと評価されています。攻撃者がアプリに細工したファイルをアップロードし、添付されれば足ります。variant、preview、analyzeの呼び出しがアプリ側になくても成立します。
被害は3段階に分かれます。まず、サーバー上の任意のファイルを書き込まれます。次に、保存先がDiskサービスなら、アプリのプロセスが読める任意のファイルも読み出されます。読み出されるファイルには、secret_key_baseや外部システムの認証情報が含まれるのが普通です。最後に、それらを使ってリモートコード実行や、外部システムへの横展開に進む恐れがあります。
今すぐやること
-
1
修正版とmini_magick 5.1以上に更新する
8.1系は8.1.4.1、8.0系は8.0.5.2に更新します。修正版は、ImageMagick用のセキュリティポリシーを同梱し、MiniMagickが起動するすべてのImageMagickプロセスに適用します。この適用にmini_magick 5.1以上が必要で、古いままだと起動時に例外で止まります。更新後は、版が上がったことを確認します。
bundle list | grep -E "activestorage|mini_magick" -
2
更新後も追加の設定が要るアプリを洗い出す
PostScriptやPDFをImageMagickで描画するアプリは、ホスト側のpolicy.xmlで、gs delegateと使っているcoderを再び許可します。ホスト側で許可したcoderは、同梱ポリシーの拒否より優先されるためです。起動後にMiniMagick.cli_envを差し替える、MiniMagick.cli_prefixで環境変数を消す、独自のMiniMagick::Shellを入れているアプリは、同梱ポリシーを受け取れません。この場合も、ImageMagickのシステムポリシーに同じ規則を書きます。GraphicsMagickはImageMagickのポリシーを読まないので、同様に対応します。
-
3
Disk保存なら秘密情報をすべて入れ替える
更新したうえで、secret_key_baseとアプリのプロセスが読めるすべての秘密情報を変更します。マスターキー、config/credentials.yml.encの中身、ストレージとデータベースの認証情報、サードパーティのトークンも含みます。漏れた可能性のある旧い値は、フォールバックとして残さないでください。
-
4
侵害の跡を調べる
任意のファイル書き込みが可能なため、更新前の期間について、不審なアップロードのログや、サーバー上に覚えのないファイルがないかを調べます。外部システムの認証情報が読み出された可能性があれば、そちらのアクセスログも確認します。
-
5
Rails告知で自分の系列の対応を確かめる
修正版として挙がっているのは8.0系と8.1系だけです。それより前の系列を使っている場合は、Railsのセキュリティ告知で対応を確認し、先に回避策を入れます。
すぐ更新できないとき
すぐに更新できないときは、修正版が同梱するポリシーの規則を、ImageMagickのシステムポリシー（たとえば /etc/ImageMagick-7/policy.xml）に写します。写す元は、修正版にあるactivestorage/lib/active_storage/image_magick/policy.xmlです。最低限、MSL coder、Ghostscript系のcoder、gs delegateを拒否します。
<policy domain="coder" rights="none" pattern="MSL"/><policy domain="delegate" rights="none" pattern="gs"/><policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>
すぐに版を上げられない場合のパッチとして、8.1系にはコミット468aa9a、8.0系にはコミットea8c401が公開されています。PostScriptやPDFをImageMagickで描画しているアプリでは、上の拒否が描画を止めます。更新前に影響を確認してください。
背景
Active Storageは、Railsでクラウドなどにファイルをアップロードし、Active Recordのオブジェクトに添付するための部品です。会員のアイコンや投稿画像など、外部の利用者から受け取るファイルを扱う場面で使われます。画像の解析は添付した時点で自動で動くので、アプリの作者が画像処理のコードを書いていなくても、処理は走ります。
ImageMagickは、細工された画像を入力にするとファイルの読み書きなど本来の用途を超える動作を起こすことがあり、2016年には「ImageTragick」と呼ばれた一連の脆弱性が問題になりました。対策は、ポリシーファイルで危険なcoderを無効にすることです。今回の勧告では、DebianとUbuntuのパッケージが入れるポリシーは、関係するcoderを拒否しないとされています。守りを各アプリのホスト設定に任せていたため、Rails側で何も制限していない状態が残っていました。修正版は、Rails自身がポリシーを同梱し、MiniMagick経由のすべてのプロセスに適用する形に変わっています。
よくある質問
Q.ImageMagick本体の更新も必要ですか。
Q.修正版はいつから出ていますか。
まだ分かっていないこと
- 報告された攻撃経路のほかに、どんな経路がありうるかは公表されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Active Storage makes it simple to upload and reference files in cloud services and attach those files to Active Record objects. Prior to 8.1.4.1 and 8.0.5.2, a Rails application that processes attachments with ImageMagick may allow an unauthenticated attacker to write arbitrary files on the server and, when attachments are stored with the Disk service, to read arbitrary files readable by the application process. Those files typically include secret_key_base and credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems. ImageMagick selects a coder from the content of the file it is given, and some coders act on files named inside the image rather than on the image itself. Active Storage constrained none of ImageMagick's coders, and the ImageMagick analyzer runs when a file is attached, so an attacker who can upload a crafted file may be able to invoke one. Attaching the upload is sufficient; no variant, preview, or analyze call is required. One specific attack chain has been reported, but other attack chains may exist. An application is affected when it uses ImageMagick for Active Storage image processing through config.active_storage.variant_processor = :mini_magick, runs ImageMagick under a security policy that does not already deny the involved coders, and allows uploads from untrusted users. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.
出典: CVE.org (CVE Program・cvelistV5) NVD