Lỗ hổng Rails Active Storage: kiểm tra ba thiết lập trước ngày 7/11

Lỗ hổng CVSS 9.8 trong Rails Active Storage cho phép một lần tải ảnh lên ghi tệp trên máy chủ. Kiểm tra ba thiết lập, nâng cấp và lưu ý hạn chót của Rails 8.0.

Hầu như mọi ứng dụng Rails cho phép tải lên ảnh đại diện, tài liệu hay ảnh sản phẩm đều xử lý tệp đó qua Active Storage. Ngày 4 tháng 11 năm 2026, nhóm Rails đã công bố một khuyến cáo bảo mật nghiêm trọng liên quan đến luồng tải lên này. Với một số cấu hình phổ biến, chỉ một tệp tải lên được chế tạo đặc biệt cũng có thể giúp kẻ tấn công chưa xác thực ghi tệp lên máy chủ của bạn.

Bạn có bị ảnh hưởng hay không phụ thuộc vào ba thiết lập rất dễ kiểm tra. Bài viết này giải thích lỗ hổng, hướng dẫn cách kiểm tra từng thiết lập và liệt kê những việc cần làm nếu bạn chưa thể nâng cấp ngay hôm nay. Điều này đặc biệt quan trọng với các nhóm dùng Rails 8.0, vì hỗ trợ bảo mật cho nhánh này kết thúc vào ngày 7 tháng 11 năm 2026.

Bản chất của lỗ hổng

Khi một tệp được đính kèm, Active Storage chạy một analyzer để đọc các thông tin cơ bản như kích thước ảnh. Với bộ xử lý :mini_magick, analyzer này chuyển tệp cho ImageMagick. ImageMagick hỗ trợ nhiều định dạng thông qua các mô-đun gọi là coder, và một số coder rất mạnh: commit sửa lỗi cho thấy một tệp SVG được tải lên có thể đi tới coder MSL, một định dạng kịch bản có thể đọc và ghi các tệp được chỉ định trong kịch bản. Active Storage không giới hạn những coder mà tệp tải lên có thể chạm tới, nên policy ImageMagick trên máy chủ là lớp bảo vệ duy nhất.

Có hai chi tiết khiến vấn đề trở nên nghiêm trọng. Thứ nhất, analyzer chạy ngay khi đính kèm, nên không cần tạo variant, bản xem trước hay gọi analyze một cách tường minh: chỉ cần chấp nhận tệp tải lên là đủ. Thứ hai, các ứng dụng lưu tệp bằng dịch vụ Disk còn có thể bị buộc đọc bất kỳ tệp nào mà tiến trình ứng dụng đọc được. Điều đó bao gồm secret_key_base và thông tin xác thực của các hệ thống khác, có thể dẫn đến thực thi mã từ xa hoặc di chuyển ngang (lateral movement).

Khuyến cáo này được RyotaK của GMO Flatt Security báo cáo qua HackerOne. Nhóm Rails lưu ý rằng chỉ một chuỗi tấn công được báo cáo và họ không cho rằng đó là chuỗi duy nhất. Khuyến cáo không cho biết lỗ hổng đã bị khai thác hay chưa.

Kiểm tra mức độ phơi nhiễm theo ba điều kiện

Bạn chỉ bị ảnh hưởng khi cả ba điều kiện đều thỏa mãn. Hãy kiểm tra lần lượt; nếu bất kỳ điều kiện nào không đúng, chuỗi tấn công này không áp dụng, dù nâng cấp vẫn là lựa chọn đúng đắn.

Điều kiện	Nơi cần kiểm tra	Có rủi ro khi
1. Bộ xử lý variant	config.active_storage.variant_processor và load_defaults	Giá trị là :mini_magick (mặc định với load_defaults 6.1 hoặc cũ hơn)
2. Policy của ImageMagick	Tệp policy.xml trên máy chủ	Không chặn MSL, các coder Ghostscript và delegate gs (policy mặc định của Debian và Ubuntu không chặn)
3. Ai có thể tải lên	Các biểu mẫu tải lên và API của bạn	Người dùng không tin cậy có thể đính kèm tệp

1. Active Storage đang dùng bộ xử lý nào?

Tìm trong cấu hình và hỏi trực tiếp ứng dụng đang chạy:

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Từ Rails 7.0, giá trị mặc định là :vips, nhưng các ứng dụng được nâng cấp từ phiên bản cũ thường vẫn nạp giá trị mặc định cũ hoặc đặt :mini_magick một cách tường minh. Hãy kiểm tra thêm bundle info mini_magick: nếu gem này có trong bundle, hãy tìm xem nó được dùng ở đâu.

2. Policy ImageMagick của bạn có chặn các coder nguy hiểm không?

Liệt kê policy mà ImageMagick thực sự nạp trên từng máy chủ ứng dụng và worker:

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

Tìm các quy tắc có rights="none" cho coder MSL, các coder PostScript và PDF, và delegate gs. Nếu bạn dùng nguyên policy đóng gói sẵn của Debian hoặc Ubuntu mà không chỉnh sửa, hãy coi như chúng chưa bị chặn. Lưu ý rằng image container và máy chủ worker có thể chạy bản build ImageMagick khác với máy chủ web.

3. Người dùng không tin cậy có thể tải tệp lên không?

Liệt kê mọi nơi một tệp đi tới attach, has_one_attached hoặc has_many_attached, bao gồm API, direct upload và các công cụ quản trị nhập tệp từ bên ngoài. Đăng ký công khai có trường ảnh đại diện cũng được tính là không tin cậy.

Cách khắc phục: lộ trình nâng cấp theo từng nhánh

Các bản phát hành đã sửa lỗi là Rails 8.1.4.1 và Rails 8.0.5.2. Tổng cộng chúng sửa 21 vấn đề bảo mật, vì vậy đáng cài đặt ngay cả khi bạn không bị ảnh hưởng bởi lỗ hổng này.

Nhánh bạn đang dùng	Việc cần làm
8.1	Nâng cấp lên 8.1.4.1
8.0	Nâng cấp lên 8.0.5.2 ngay, sau đó lên kế hoạch chuyển sang 8.1: hỗ trợ bảo mật cho 8.0 kết thúc vào ngày 7 tháng 11 năm 2026
7.2 và cũ hơn	Sẽ không có bản sửa. Áp dụng biện pháp tạm thời bằng policy bên dưới và nâng cấp lên 8.0 trở lên

Các ứng dụng dùng :mini_magick còn cần mini_magick 5.1 trở lên. Với phiên bản cũ hơn, bản phát hành đã sửa sẽ báo lỗi khi khởi động, vì vậy hãy cập nhật cả hai gem cùng lúc và thử khởi động trên môi trường staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

Các bản phát hành đã sửa có kèm policy ImageMagick riêng, nhưng hãy xác nhận rằng nó thực sự được ImageMagick áp dụng. Policy này không có hiệu lực nếu ứng dụng của bạn thay thế MiniMagick.cli_env sau khi khởi động, dùng MiniMagick.cli_prefix, hoặc cài MiniMagick::Shell riêng; những ứng dụng đó cần đưa các quy tắc vào policy hệ thống. GraphicsMagick hoàn toàn không đọc policy của ImageMagick. Policy đi kèm cũng được bổ sung vào policy.xml của máy chủ chứ không thay thế nó, nên một quy tắc cho phép trong tệp đó, kể cả ký tự đại diện, sẽ ghi đè quy tắc chặn.

Cùng các bản phát hành này còn sửa một lỗ hổng thứ hai, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage chuyển tệp tải lên cho ImageMagick và FFmpeg dưới tên tạm vẫn giữ phần mở rộng gốc, nên kẻ tấn công kiểm soát được tên tệp và content type khai báo có thể tác động đến việc bộ giải mã nào được chạy. Các biện pháp tạm thời của Rails cho lỗ hổng này chỉ áp dụng cho FFmpeg, thêm một lý do để nâng cấp thay vì dựa vào biện pháp tạm thời.

Một xu hướng, không phải sự cố đơn lẻ

Tháng 7 năm 2026, CVE-2026-66066 là một lỗ hổng nghiêm trọng khác của Active Storage, ảnh hưởng đến các ứng dụng dùng libvips. Ứng dụng dùng ImageMagick khi đó không bị ảnh hưởng bởi đường tấn công ấy, nhưng lại bị ảnh hưởng bởi lỗ hổng lần này. Hai lỗ hổng nghiêm trọng trong bốn tháng, qua cả hai thư viện ảnh được hỗ trợ, cho thấy cùng một bài học: xử lý ảnh là một bề mặt tấn công lớn, và Active Storage chạy nó trên tệp của người lạ ngay khi tệp được đính kèm.

Chỉ đổi bộ xử lý thì chưa phải là giải pháp. Điều bảo vệ bạn là coi thư viện ảnh là một phần của bề mặt tấn công: vá nó thường xuyên như framework, giới hạn nó bằng policy và nắm rõ máy chủ nào đang chạy nó. Đặc biệt, policy của ImageMagick là một thiết lập máy chủ rất dễ bị bỏ quên, vì nó nằm trong image hệ điều hành chứ không nằm trong mã nguồn ứng dụng của bạn.

Nếu bạn chưa thể nâng cấp ngay

Rails cũng đã công bố các commit bản vá cho 8.1 và 8.0. Cho đến khi có thể triển khai bản phát hành đã sửa, hãy thực hiện theo danh sách kiểm tra sau:

1. Thêm các quy tắc tối thiểu trong khuyến cáo vào policy hệ thống của ImageMagick trên mọi máy chủ xử lý tệp tải lên (ví dụ /etc/ImageMagick-7/policy.xml).
2. Bảo đảm không có quy tắc cho phép hay ký tự đại diện nào trong cùng tệp ghi đè chúng, sau đó xác nhận bằng magick -list policy.
3. Nếu bạn render PDF hoặc PostScript qua ImageMagick, hãy cho phép lại delegate gs và chỉ những coder thực sự cần, đồng thời chấp nhận rằng việc này vẫn để lại một phần rủi ro.
4. Kiểm soát việc tải lên: tạm thời giới hạn người có thể đính kèm tệp, hoặc tạm dừng tải lên ẩn danh.
5. Nếu bạn dùng dịch vụ Disk, hãy lên kế hoạch thay mới secret_key_base, master key và nội dung của config/credentials.yml.enc, thông tin xác thực của hệ thống lưu trữ và cơ sở dữ liệu, cùng các token của bên thứ ba. Không giữ lại thông tin bí mật đã bị lộ làm phương án dự phòng.

Các quy tắc tối thiểu được công bố trong khuyến cáo là:

<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}"/>

Xem đầy đủ chi tiết trong khuyến cáo bảo mật của Rails.

LOGIQ có thể hỗ trợ như thế nào

LOGIQ hỗ trợ các nhóm vận hành stack mã nguồn mở trên Linux, từ image hệ điều hành đến môi trường chạy ứng dụng. Nếu bạn cần hỗ trợ kiểm tra policy ImageMagick trên các máy chủ, hoặc lên kế hoạch chuyển khỏi một nhánh sắp hết hỗ trợ, hãy liên hệ với đội ngũ của chúng tôi.