ช่องโหว่ Rails Active Storage: ตรวจสอบ 3 การตั้งค่าก่อนวันที่ 7 พฤศจิกายน

ช่องโหว่ CVSS 9.8 ใน Rails Active Storage ทำให้การอัปโหลดรูปภาพเพียงครั้งเดียวเขียนไฟล์บนเซิร์ฟเวอร์ได้ ตรวจสอบ 3 การตั้งค่า อัปเกรด และระวังกำหนดของ Rails 8.0

แอปพลิเคชัน Rails แทบทุกตัวที่รับอัปโหลดรูปโปรไฟล์ เอกสาร หรือรูปสินค้า จะส่งไฟล์เหล่านั้นผ่าน Active Storage เมื่อวันที่ 4 พฤศจิกายน 2026 ทีม Rails ได้เผยแพร่ประกาศด้านความปลอดภัยระดับวิกฤตสำหรับเส้นทางการอัปโหลดนี้ ในการตั้งค่าที่พบบ่อยบางแบบ การอัปโหลดไฟล์ที่สร้างขึ้นเป็นพิเศษเพียงครั้งเดียวอาจทำให้ผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนเขียนไฟล์บนเซิร์ฟเวอร์ของคุณได้

คุณได้รับผลกระทบหรือไม่ขึ้นอยู่กับการตั้งค่า 3 อย่างที่ตรวจสอบได้ง่าย บทความนี้อธิบายช่องโหว่ วิธีตรวจสอบการตั้งค่าแต่ละอย่าง และสิ่งที่ควรทำหากคุณยังอัปเกรดไม่ได้ในวันนี้ เรื่องนี้สำคัญที่สุดสำหรับทีมที่ใช้ Rails 8.0 เพราะการสนับสนุนด้านความปลอดภัยของสาขานี้จะสิ้นสุดในวันที่ 7 พฤศจิกายน 2026

ช่องโหว่นี้คืออะไร

เมื่อมีการแนบไฟล์ Active Storage จะเรียกใช้ analyzer เพื่ออ่านข้อมูลพื้นฐาน เช่น ขนาดของรูปภาพ เมื่อใช้ตัวประมวลผล :mini_magick analyzer จะส่งไฟล์ต่อให้ ImageMagick ซึ่งรองรับรูปแบบไฟล์จำนวนมากผ่านโมดูลที่เรียกว่า coder และบาง coder มีความสามารถสูงมาก: commit ที่แก้ไขแสดงให้เห็นว่าไฟล์ SVG ที่อัปโหลดสามารถไปถึง coder MSL ซึ่งเป็นรูปแบบสคริปต์ที่อ่านและเขียนไฟล์ที่ระบุในสคริปต์ได้ Active Storage ไม่ได้จำกัดว่าไฟล์ที่อัปโหลดจะเข้าถึง coder ใดได้บ้าง ดังนั้น policy ของ ImageMagick บนเซิร์ฟเวอร์จึงเป็นการป้องกันเพียงชั้นเดียว

มีรายละเอียด 2 ประการที่ทำให้เรื่องนี้ร้ายแรง ประการแรก analyzer ทำงานทันทีเมื่อแนบไฟล์ จึงไม่จำเป็นต้องสร้าง variant พรีวิว หรือเรียก analyze อย่างชัดแจ้ง: แค่รับไฟล์อัปโหลดก็เพียงพอแล้ว ประการที่สอง แอปพลิเคชันที่จัดเก็บไฟล์ด้วยบริการ Disk ยังอาจถูกบังคับให้อ่านไฟล์ใดก็ได้ที่โปรเซสของแอปพลิเคชันอ่านได้ ซึ่งรวมถึง secret_key_base และข้อมูลรับรองของระบบอื่น ๆ และอาจนำไปสู่การรันโค้ดจากระยะไกลหรือการเคลื่อนที่ในแนวราบ (lateral movement)

ประกาศนี้รายงานโดย RyotaK จาก GMO Flatt Security ผ่าน HackerOne ทีม Rails ระบุว่ามีการรายงานห่วงโซ่การโจมตีเพียงหนึ่งแบบ และพวกเขาไม่ได้ถือว่านั่นเป็นแบบเดียวที่มีอยู่ ประกาศไม่ได้ระบุว่าช่องโหว่นี้ถูกนำไปใช้โจมตีจริงแล้วหรือไม่

การทดสอบความเสี่ยงด้วย 3 เงื่อนไข

คุณจะได้รับผลกระทบก็ต่อเมื่อทั้ง 3 เงื่อนไขเป็นจริง ให้ตรวจสอบตามลำดับ หากมีเงื่อนไขใดไม่เป็นจริง ห่วงโซ่การโจมตีนี้จะใช้ไม่ได้ แต่การอัปเกรดก็ยังเป็นสิ่งที่ควรทำ

เงื่อนไข	จุดที่ต้องตรวจสอบ	มีความเสี่ยงเมื่อ
1. ตัวประมวลผล variant	config.active_storage.variant_processor และ load_defaults	ค่าเป็น :mini_magick (ค่าเริ่มต้นของ load_defaults 6.1 หรือเก่ากว่า)
2. policy ของ ImageMagick	ไฟล์ policy.xml บนเซิร์ฟเวอร์	ไม่ได้บล็อก MSL, coder ของ Ghostscript และ delegate gs (policy เริ่มต้นของ Debian และ Ubuntu ไม่ได้บล็อก)
3. ใครอัปโหลดได้บ้าง	ฟอร์มอัปโหลดและ API ของคุณ	ผู้ใช้ที่ไม่น่าเชื่อถือสามารถแนบไฟล์ได้

1. Active Storage ใช้ตัวประมวลผลใด

ค้นหาในการตั้งค่า และสอบถามจากแอปพลิเคชันที่กำลังทำงานอยู่:

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

ตั้งแต่ Rails 7.0 ค่าเริ่มต้นคือ :vips แต่แอปพลิเคชันที่อัปเกรดมาจากเวอร์ชันเก่ามักยังโหลดค่าเริ่มต้นแบบเก่า หรือกำหนด :mini_magick ไว้อย่างชัดแจ้ง ให้ตรวจสอบ bundle info mini_magick ด้วย: หาก gem นี้อยู่ใน bundle ของคุณ ให้ค้นหาว่ามีการใช้งานที่ใด

2. policy ของ ImageMagick บล็อก coder ที่เป็นอันตรายหรือไม่

แสดงรายการ policy ที่ ImageMagick โหลดใช้งานจริงบนเซิร์ฟเวอร์แอปพลิเคชันและ worker ทุกเครื่อง:

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

มองหากฎที่มี rights="none" สำหรับ coder MSL, coder ของ PostScript และ PDF รวมถึง delegate gs หากคุณใช้ policy ที่มากับแพ็กเกจของ Debian หรือ Ubuntu โดยไม่ได้แก้ไข ให้สันนิษฐานว่ายังไม่ได้บล็อก และอย่าลืมว่าคอนเทนเนอร์อิมเมจและเครื่อง worker อาจใช้ ImageMagick คนละบิลด์กับเว็บเซิร์ฟเวอร์

3. ผู้ใช้ที่ไม่น่าเชื่อถืออัปโหลดไฟล์ได้หรือไม่

ระบุทุกจุดที่ไฟล์ไปถึง attach, has_one_attached หรือ has_many_attached รวมถึง API, direct upload และเครื่องมือผู้ดูแลระบบที่นำเข้าไฟล์จากภายนอก การสมัครสมาชิกแบบสาธารณะที่มีช่องรูปโปรไฟล์ก็นับเป็นแหล่งที่ไม่น่าเชื่อถือ

วิธีแก้ไข: เส้นทางการอัปเกรดของแต่ละสาขา

รุ่นที่แก้ไขแล้วคือ Rails 8.1.4.1 และ Rails 8.0.5.2 ซึ่งแก้ไขปัญหาด้านความปลอดภัยรวม 21 รายการ จึงคุ้มค่าที่จะติดตั้งแม้คุณจะไม่ได้รับผลกระทบจากช่องโหว่นี้

สาขาที่คุณใช้	สิ่งที่ต้องทำ
8.1	อัปเกรดเป็น 8.1.4.1
8.0	อัปเกรดเป็น 8.0.5.2 ทันที จากนั้นวางแผนย้ายไป 8.1: การสนับสนุนด้านความปลอดภัยของ 8.0 สิ้นสุดในวันที่ 7 พฤศจิกายน 2026
7.2 และเก่ากว่า	จะไม่มีการออกรุ่นแก้ไข ให้ใช้วิธีแก้ปัญหาชั่วคราวด้วย policy ด้านล่าง และอัปเกรดเป็น 8.0 ขึ้นไป

แอปพลิเคชันที่ใช้ :mini_magick ยังต้องใช้ mini_magick 5.1 ขึ้นไป ด้วย หากใช้เวอร์ชันเก่ากว่า รุ่นที่แก้ไขแล้วจะแจ้งข้อผิดพลาดตอนบูต ดังนั้นให้อัปเดต gem ทั้งสองพร้อมกันและทดสอบการบูตบน staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

รุ่นที่แก้ไขแล้วมาพร้อม policy ของ ImageMagick เอง แต่ให้ตรวจสอบว่า policy นั้นถูกนำไปใช้กับ ImageMagick จริง policy นี้จะไม่มีผลหากแอปพลิเคชันของคุณแทนที่ MiniMagick.cli_env หลังบูต ใช้ MiniMagick.cli_prefix หรือติดตั้ง MiniMagick::Shell ของตัวเอง แอปพลิเคชันเหล่านั้นต้องใส่กฎไว้ใน policy ของระบบ ส่วน GraphicsMagick ไม่ได้อ่าน policy ของ ImageMagick เลย นอกจากนี้ policy ที่มาพร้อมรุ่นใหม่จะเพิ่มเข้าไปใน policy.xml ของเซิร์ฟเวอร์แทนที่จะแทนที่ไฟล์ ดังนั้นกฎอนุญาตในไฟล์นั้น รวมถึงไวลด์การ์ด จะมีผลเหนือกว่าการบล็อก

รุ่นเดียวกันนี้ยังแก้ไขช่องโหว่ที่สอง คือ GHSA-v924-7rp8-4mxh (CVSS 8.8) Active Storage ส่งไฟล์อัปโหลดให้ ImageMagick และ FFmpeg โดยใช้ชื่อไฟล์ชั่วคราวที่ยังคงนามสกุลเดิมไว้ ผู้โจมตีที่ควบคุมชื่อไฟล์และ content type ที่ประกาศได้จึงสามารถมีอิทธิพลต่อการเลือกตัวถอดรหัสที่จะทำงาน วิธีแก้ปัญหาชั่วคราวของ Rails สำหรับช่องโหว่นี้ครอบคลุมเฉพาะ FFmpeg ซึ่งเป็นอีกเหตุผลหนึ่งที่ควรอัปเกรดแทนการพึ่งวิธีแก้ปัญหาชั่วคราว

เป็นรูปแบบที่เกิดซ้ำ ไม่ใช่เหตุการณ์ครั้งเดียว

ในเดือนกรกฎาคม 2026 CVE-2026-66066 เป็นช่องโหว่ร้ายแรงอีกตัวหนึ่งของ Active Storage ที่ส่งผลต่อแอปพลิเคชันที่ใช้ libvips แอปพลิเคชันที่ใช้ ImageMagick ไม่ได้รับผลกระทบจากเส้นทางนั้น แต่ได้รับผลกระทบจากช่องโหว่ครั้งนี้ ช่องโหว่ร้ายแรง 2 ตัวในเวลา 4 เดือน ผ่านไลบรารีรูปภาพทั้งสองตัวที่รองรับ ชี้ไปยังบทเรียนเดียวกัน: การประมวลผลรูปภาพเป็นพื้นผิวการโจมตีขนาดใหญ่ และ Active Storage ประมวลผลไฟล์จากบุคคลที่ไม่รู้จักทันทีที่ไฟล์ถูกแนบ

การเปลี่ยนตัวประมวลผลเพียงอย่างเดียวไม่ใช่การแก้ไข สิ่งที่ปกป้องคุณได้คือการมองไลบรารีรูปภาพเป็นส่วนหนึ่งของพื้นผิวการโจมตี: แพตช์ให้ทันสมัยเหมือนเฟรมเวิร์ก จำกัดด้วย policy และรู้ว่าเครื่องใดบ้างที่รันไลบรารีนี้ โดยเฉพาะ policy ของ ImageMagick เป็นการตั้งค่าเซิร์ฟเวอร์ที่ถูกลืมได้ง่าย เพราะอยู่ในอิมเมจของระบบปฏิบัติการ ไม่ใช่ในโค้ดของแอปพลิเคชัน

หากยังอัปเกรดทันทีไม่ได้

Rails ได้เผยแพร่ commit แพตช์สำหรับ 8.1 และ 8.0 ด้วย ระหว่างที่ยังไม่สามารถดีพลอยรุ่นที่แก้ไขแล้ว ให้ดำเนินการตามเช็กลิสต์นี้:

1. เพิ่มกฎขั้นต่ำจากประกาศลงใน policy ระดับระบบของ ImageMagick บนทุกเครื่องที่ประมวลผลไฟล์อัปโหลด (เช่น /etc/ImageMagick-7/policy.xml)
2. ตรวจสอบให้แน่ใจว่าไม่มีกฎอนุญาตหรือไวลด์การ์ดในไฟล์เดียวกันที่มีผลเหนือกฎเหล่านั้น แล้วยืนยันด้วย magick -list policy
3. หากคุณเรนเดอร์ PDF หรือ PostScript ผ่าน ImageMagick ให้อนุญาต delegate gs อีกครั้งและเฉพาะ coder ที่จำเป็นเท่านั้น โดยยอมรับว่ายังคงมีความเสี่ยงหลงเหลืออยู่บ้าง
4. ควบคุมการอัปโหลด: จำกัดผู้ที่แนบไฟล์ได้เป็นการชั่วคราว หรือหยุดการอัปโหลดแบบไม่ระบุตัวตนไว้ก่อน
5. หากคุณใช้บริการ Disk ให้วางแผนหมุนเวียน secret_key_base, master key และเนื้อหาใน config/credentials.yml.enc, ข้อมูลรับรองของระบบจัดเก็บและฐานข้อมูล รวมถึงโทเค็นของบริการภายนอก อย่าเก็บข้อมูลลับที่รั่วไหลแล้วไว้เป็นตัวสำรอง

กฎขั้นต่ำที่เผยแพร่ในประกาศมีดังนี้:

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

อ่านรายละเอียดทั้งหมดได้ใน ประกาศด้านความปลอดภัยของ Rails

LOGIQ ช่วยคุณได้อย่างไร

LOGIQ สนับสนุนทีมที่ใช้งานสแต็กโอเพนซอร์สบน Linux ตั้งแต่อิมเมจระบบปฏิบัติการไปจนถึงรันไทม์ของแอปพลิเคชัน หากคุณต้องการความช่วยเหลือในการตรวจสอบ policy ของ ImageMagick บนเซิร์ฟเวอร์ทั้งหมด หรือวางแผนย้ายออกจากสาขาที่กำลังจะหมดการสนับสนุน ติดต่อทีมของเรา