Lỗ hổng nghiêm trọng trong Rails cho phép ghi tệp qua tải lên ImageMagick
Các phiên bản Ruby on Rails trước 8.0.5.2 và 8.1.4.1 chứa một lỗ hổng bảo mật nghiêm trọng trong Active Storage, cho phép kẻ tấn công ghi tệp thông qua các hình ảnh được tạo thủ công để gửi lên ImageMagick.
Bài được dịch tự động từ bản gốc tiếng Anh.
Một lỗ hổng bảo mật nghiêm trọng trong Ruby on Rails cho phép kẻ tấn công không cần xác thực vẫn có thể ghi các tệp tùy ý lên máy chủ bằng cách tải lên những hình ảnh được thiết kế đặc biệt. Dự án Rails đã phát hành bản vá trong các phiên bản 8.1.4.1 và 8.0.5.2 vào ngày 4 tháng 11 năm 2026, khắc phục lỗi trong thành phần Active Storage khi sử dụng cùng với ImageMagick.
Chuyện gì đã xảy ra
Lỗ hổng nằm ở cách Active Storage xử lý việc tải lên tệp khi được cấu hình để dùng ImageMagick cho mục đích xử lý hình ảnh. Khi một ứng dụng chấp nhận tải lên tệp, Active Storage sẽ chạy một trình phân tích để xác định loại tệp. Quá trình này kích hoạt ImageMagick kiểm tra nội dung, từ đó chọn một trình xử lý định dạng (gọi là coder) dựa trên những gì nó tìm thấy bên trong tệp. Một số coder này được thiết kế để thao tác trên các tệp bên ngoài được tham chiếu trong dữ liệu hình ảnh, chứ không chỉ riêng bản thân hình ảnh đó.
Trong trường hợp cụ thể này, kẻ tấn công có thể tải lên một tệp SVG gọi tới coder MSL, một định dạng kịch bản có khả năng đọc và ghi các tệp được chỉ định trong kịch bản của nó. Do Active Storage không hạn chế những coder nào được phép sử dụng trong quá trình phân tích, chính sách mặc định của ImageMagick trên máy chủ trở thành lớp phòng thủ duy nhất. Trên nhiều hệ thống, bao gồm cả các hệ điều hành Debian hoặc Ubuntu, chính sách mặc định không chặn những coder nguy hiểm này. Kết quả là, chỉ cần đính kèm một tệp độc hại là đủ để khai thác lỗ hổng, mà không cần phải tạo bản xem trước hay biến đổi hình ảnh.
Nếu ứng dụng lưu trữ tệp bằng dịch vụ Disk, kẻ tấn công cũng có thể đọc bất kỳ tệp nào mà ứng dụng có quyền truy cập. Điều này thường bao gồm các thông tin đăng nhập nhạy cảm như secret_key_base, mật khẩu cơ sở dữ liệu và token API của bên thứ ba. Việc tiếp cận những bí mật này có thể dẫn đến thực thi mã từ xa hoặc di chuyển ngang sang các hệ thống kết nối khác. Đội ngũ Rails đánh giá lỗ hổng này ở mức 9.8/10 theo thang điểm CVSS, cho thấy mức độ nghiêm trọng gần như tối đa.
Chi tiết quan trọng
- Lỗ hổng được theo dõi dưới mã GHSA-f3w6-w445-fwh9 và ảnh hưởng đến các phiên bản Rails trước 8.0.5.2 và 8.1.4.1.
- Nó yêu cầu ứng dụng phải sử dụng
config.active_storage.variant_processor = :mini_magick, đây là cấu hình mặc định cho các phiên bản Rails cũ hơn. - Vector tấn công liên quan đến việc tải lên một tệp được thiết kế thủ công, chẳng hạn như SVG, nhằm kích hoạt coder MSL của ImageMagick trong giai đoạn phân tích tệp đính kèm.
- Các ứng dụng sử dụng dịch vụ Disk để lưu trữ chịu rủi ro cao hơn vì kẻ tấn công có thể đọc các tệp cấu hình nhạy cảm và bí mật từ máy chủ.
- Bản vá giới thiệu một chính sách bảo mật ImageMagick nghiêm ngặt, chặn các coder nguy hiểm như MSL, Ghostscript và những coder cho phép gián tiếp hóa tệp.
- Một lỗ hổng nghiêm trọng thứ hai, GHSA-v924-7rp8-4mxh, cũng đã được khắc phục trong các bản phát hành này, liên quan đến cách phần mở rộng tệp ảnh hưởng đến việc lựa chọn bộ giải mã trong FFmpeg và ImageMagick.
Bối cảnh
Active Storage là khung chuẩn trong Rails để quản lý các tệp đính kèm. Nó ủy quyền các tác vụ xử lý hình ảnh cho các thư viện bên ngoài, phổ biến là ImageMagick hoặc libvips. ImageMagick là một công cụ mạnh mẽ hỗ trợ hàng trăm định dạng hình ảnh, mỗi định dạng được xử lý bởi một coder cụ thể. Mặc dù tính linh hoạt này hữu ích cho nhà phát triển, nó lại tiềm ẩn rủi ro bảo mật nếu một số coder được phép thực thi kịch bản hoặc truy cập hệ thống tệp vượt ra ngoài phạm vi tệp hình ảnh trực tiếp.
Các chính sách bảo mật trong ImageMagick được định nghĩa trong các tệp XML, quy định rõ những thao tác và coder nào được phép. Trong lịch sử, nhiều bản phân phối Linux đi kèm với các chính sách lỏng lẻo để đảm bảo tương thích với nhiều quy trình làm việc khác nhau. Lỗ hổng này nhấn mạnh sự nguy hiểm của việc phụ thuộc vào các thiết lập mặc định cấp hệ thống cho bảo mật ứng dụng, đặc biệt là khi xử lý đầu vào không đáng tin cậy từ người dùng. Bản vá gần đây chuyển trách nhiệm về phía khung ứng dụng bằng cách đóng gói một chính sách hạn chế trực tiếp cùng với Rails.
Tại sao điều này quan trọng
Đối với các đội ngũ vận hành ứng dụng Rails tự host, lỗ hổng này đại diện cho mối đe dọa trực tiếp đối với tính toàn vẹn của hạ tầng. Khác với một số lỗi đòi hỏi các điều kiện phức tạp để khai thác, lỗi này được kích hoạt chỉ bằng hành động cơ bản là tải lên một tệp. Nếu ứng dụng của bạn chấp nhận tải lên từ người dùng công khai hoặc thậm chí nhân viên nội bộ, nó có thể đang bị lộ. Khả năng kẻ tấn công ghi tệp có nghĩa là họ có thể cài đặt cửa hậu (backdoor), sửa đổi mã ứng dụng hoặc trích xuất dữ liệu bằng cách đọc các tệp cấu hình.
Tác động càng trầm trọng hơn đối với các ứng dụng sử dụng dịch vụ Disk, vì việc lộ các bí mật như secret_key_base làm sụp đổ mô hình bảo mật của toàn bộ ứng dụng. Khi kẻ tấn công có được những khóa này, chúng có thể giả mạo cookie phiên, giải mã thông tin đăng nhập đã lưu và mạo danh người dùng. Điều này khiến việc khắc phục ngay lập tức trở nên cấp thiết, vì cửa sổ khai thác rất rộng và thiệt hại tiềm tàng là vô cùng lớn. Hơn nữa, các phiên bản Rails cũ không còn nhận được bản vá bảo mật, buộc các đội ngũ trên hệ thống legacy phải tìm kiếm các chiến lược giảm thiểu thay thế.
Bạn có thể làm gì
- Nâng cấp ngay lập tức lên Rails 8.1.4.1 hoặc 8.0.5.2, và đảm bảo gem mini_magick phiên bản 5.1 trở lên đã được cài đặt.
- Xác minh rằng chính sách ImageMagick mới đã có hiệu lực bằng cách chạy lệnh
bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. - Nếu bạn không thể nâng cấp, hãy sao chép thủ công chính sách hạn chế từ
activestorage/lib/active_storage/image_magick/policy.xmlvào tệp chính sách ImageMagick của hệ thống. - Xoay vòng tất cả các bí mật ngay lập tức nếu ứng dụng của bạn sử dụng dịch vụ Disk, bao gồm
secret_key_base, thông tin đăng nhập cơ sở dữ liệu và token API, vì chúng có thể đã bị lộ. - Kiểm tra các cấu hình ImageMagick tùy chỉnh có thể ghi đè lên các hạn chế mới, chẳng hạn như ký tự đại diện trong
policy.xmlcho phép bật lại các coder đã bị chặn. - Cân nhắc chuyển sang libvips nếu có thể, vì nó không bị ảnh hưởng bởi chuỗi lỗ hổng liên quan đến ImageMagick cụ thể này.



