細工された画像が、標準的なアバターアップロードフォームをWebアプリケーションの機密情報を窃取するための隠れた侵入経路に変えてしまう恐れがあります。脆弱なRuby on Railsサーバーでは、暗号化キーやデータベースパスワード、サービストークン、クラウド認証情報が流出する可能性があります。特定の設定下では、攻撃者はアクティブなユーザーアカウントすら必要とせずにこのエクスプロイトを実行できます。
Ethiackの研究者らは、Ruby on RailsのActive Storageに存在する重大なKindaRails2Shell Rails RCE脆弱性を発見しました。Active Storageは、Ruby on Railsにおけるファイルアップロードと画像処理を統合的に扱うコンポーネントです。CVE-2026-66066として識別されるこの深刻な脆弱性は、任意のファイル読み取りとリモートコード実行を引き起こす可能性があります。さらに、相互に接続されたシステムへの深刻な侵入も許してしまいます。
Active Storageにおけるlibvipsの役割
この脆弱性は、Active Storageがアバターやサムネイル、その他の画像バリエーションを生成する際に使用するlibvipsライブラリに起因します。libvipsは、個別のオペレーションとローダーを通じて複数のフォーマットに対応しています。これらのローダーの一部は、サードパーティ製の依存関係に大きく依存しています。libvipsの開発者は特定のオペレーションが信頼できないファイルの処理には安全でないと明言していますが、Active Storageはこれまでそうしたオペレーションをブロックしていませんでした。
攻撃者は、標準的なプロフィール画像の投稿フォームを通じて、細工したファイルをアップロードできます。処理の過程で、libvipsはファイルの内容を解析し、対応するローダーを自動的に起動します。その結果、この悪意あるペイロードが安全でないオペレーションを引き起こす可能性があります。この動作により、Webアプリケーションのプロセスがアクセス可能な任意のファイルの内容が暴露されてしまいます。
この攻撃が成功するには、対象のアプリケーションが画像処理の主要な手段としてlibvipsを利用している必要があります。さらに、信頼できないソースからのファイルアップロードを明示的に許可している必要もあります。調査を行った研究者らによると、全体的なリスクは使用しているlibvipsのビルドや、それに関連するサードパーティ製ライブラリによって変動するとのことです。なお、ImageMagickに依存しているアプリケーションは、この特定の攻撃ベクトルの影響を受けません。
重大な機密情報の流出と対策
最大の危険は、環境変数や設定ファイルが流出する可能性にあります。Ruby on Railsは、こうした場所にsecret_key_baseやマスターキーを保存することが多くあります。加えて、データベースパスワードや外部サービスのトークン、Amazon S3、Google Cloud Storage、Microsoft Azureといったクラウドプロバイダーへの重要なアクセスキーもここに保存されます。これらの機密情報が流出すると、攻撃者は署名済みデータを偽造したり、ユーザーセッションを乗っ取ったり、関連するシステムへ難なく侵入したりできるようになります。リモートコード実行は、通常この攻撃がさらに高度化した結果として発生するものであり、すべての悪用の試みで必ず即座に起こる結果とは限りません。
この深刻な脆弱性は、Ruby on Railsのバージョン7.0.0から7.2.3.1、8.0.0から8.0.5、8.1.0から8.1.3に影響します。さらに、6.0.0から6.1.7.10までの旧バージョン系統についても、信頼できないユーザーからの画像を受け付ける非標準的なActive Storage設定を使用している場合に限り、リスクにさらされます。
公式のセキュリティ情報によると、開発者はActive Storageのバージョン7.2.3.2、8.0.5.1、8.1.3.1でこの問題を確実に修正しています。重要な点として、この修正を適用するにはlibvipsバージョン8.13以降が必要です。旧バージョンのライブラリには安全でないオペレーションを無効化する機能がないため、Railsフレームワークを更新するだけでは不十分です。
直ちにパッチを適用できない場合、libvips 8.13以降を実行している管理者は、一時的な対策としてVIPS_BLOCK_UNTRUSTED環境変数を設定できます。あるいは、ruby-vips 2.2.1以降を利用しているユーザーは、アプリケーションのイニシャライザ内で明示的にVips.block_untrusted(true)を呼び出すこともできます。ただし、これらの一時的な防御策は、フレームワークの包括的な更新の代わりにはなりません。
パッチの適用が完了した後、システムの管理者は、Railsプロセスがアクセス可能なすべての暗号鍵を速やかにローテーションする必要があります。この包括的な対応には、secret_key_base、マスターキー、データベースパスワード、クラウドストレージの認証情報、サードパーティ製サービスのトークンが含まれます。この更新によって脆弱性自体は確実に塞がれますが、修正が適用される以前に攻撃者がひそかに窃取していた可能性のあるキーそのものを無効化することはできません。
翻訳元: https://meterpreter.org/kindarails2shell-rails-vulnerability/
