ช่องโหว่ที่เพิ่งค้นพบใน Redis ได้จุดประกายการถกเถียงอย่างดุเดือดในชุมชนความปลอดภัยไซเบอร์ ไม่เพียงแต่เพราะผลกระทบทางเทคนิคเท่านั้น แต่ยังเป็นเพราะคะแนน CVSS 10.0 แบบเต็มที่ที่ได้รับซึ่งเป็นที่ถกเถียงกัน ช่องโหว่นี้ได้รับการตั้งชื่อว่า RediShell และติดตามเป็น CVE-2025-49844 โดยใช้ประโยชน์จากบั๊ก use-after-free อายุ 12 ปีใน Lua scripting engine ของ Redis เพื่อให้สามารถรันโค้ดจากระยะไกลได้ แม้ว่า Wiz Research จะให้คะแนนความรุนแรงสูงสุดแก่ช่องโหว่นี้ แต่ผู้เชี่ยวชาญด้านความปลอดภัยหลายคนกำลังตั้งคำถามว่าการให้คะแนนนี้สะท้อนภัยคุกคามในโลกจริงอย่างแม่นยำหรือไม่
รายละเอียดช่องโหว่
- CVE ID: CVE-2025-49844
- CVSS Score: 10.0 (วิกฤต)
- Attack Vector: สคริปต์ Lua ที่เป็นอันตรายผ่านเครือข่าย
- Prerequisites: การเข้าถึงหลังจากการยืนยันตัวตน
- Impact: การดำเนินโค้ดระยะไกล, การหลบหนี sandbox
- Affected Component: เครื่องมือสคริปต์ Lua
ความขัดแย้งเรื่องคะแนน CVSS
การถกเถียงที่ดุเดือดที่สุดมุ่งเน้นไปที่ว่าช่องโหว่ที่ต้องผ่านการยืนยันตัวตนสมควรได้รับคะแนน CVSS สูงสุด 10.0 หรือไม่ ผู้เชี่ยวชาญด้านความปลอดภัยชี้ให้เห็นว่าการให้คะแนนนี้ทำให้บั๊กของ Redis อยู่ในระดับเดียวกับช่องโหว่ที่รุนแรงที่สุดที่เคยค้นพบ ควบคู่ไปกับภัยคุกคามที่ไม่ต้องการการยืนยันตัวตนใดๆ เลย นักวิจารณ์โต้แย้งว่าช่องโหว่ที่มีชื่อเสียงอย่าง Shellshock ซึ่งได้รับคะแนน 9.5 และมีผลกระทบที่กว้างไกลกว่ามาก แสดงให้เห็นถึงความไม่สอดคล้องในการให้คะแนน CVSS
ความขัดแย้งนี้เน้นย้ำถึงปัญหาพื้นฐานของระบบ CVSS เอง ผู้ปฏิบัติงานหลายคนมองว่าเป็นเครื่องมือทางการตลาดมากกว่าการประเมินทางเทคนิคที่เชื่อถือได้ การให้คะแนนดูเหมือนจะให้ความสำคัญกับผลกระทบสูงสุดเชิงทฤษฎีมากกว่าสถานการณ์การใช้ประโยชน์ในทางปฏิบัติ ทำให้เกิดคะแนนที่สูงเกินจริงซึ่งไม่สอดคล้องกับความเสี่ยงในโลกจริง
ผลกระทบในโลกจริงที่จำกัด
แม้จะมีหัวข้อข่าวที่น่าตกใจ แต่ภัยคุกคามจริงที่เกิดจากช่องโหว่นี้ดูเหมือนจะจำกัดมากกว่าที่คะแนนเต็มแสดงให้เห็น การใช้ประโยชน์จากช่องโหว่ต้องการให้ผู้โจมตีส่งสคริปต์ Lua ที่เป็นอันตรายไปยัง Redis instance ซึ่งหมายความว่าพวกเขาต้องมีระดับการเข้าถึงระบบอยู่แล้ว การปรับใช้ที่คำนึงถึงความปลอดภัยส่วนใหญ่ใช้ Redis สำหรับสคริปต์ที่เชื่อถือได้ซึ่งเขียนโดยนักพัฒนา แทนที่จะอนุญาตให้รันโค้ดของผู้ใช้แบบไม่จำกัด
ช่องโหว่นี้โดยพื้นฐานแล้วอนุญาตให้ผู้โจมตีหลบหนีจาก Lua sandbox ของ Redis แต่สิ่งนี้ถือว่าองค์กรต่างๆ พึ่งพา sandbox นั้นเพื่อความปลอดภัยตั้งแต่แรก ในทางปฏิบัติ การปรับใช้ Redis น้อยมากที่อนุญาตให้ผู้ใช้ที่ไม่น่าเชื่อถืออัปโหลดและรันโค้ด Lua แบบไม่จำกัด ทำให้ผลกระทบของช่องโหว่เป็นเรื่องเชิงทฤษฎีมากกว่าปฏิบัติสำหรับการติดตั้งส่วนใหญ่
Lua sandbox: ฟีเจอร์ความปลอดภัยที่จำกัดสิ่งที่สคริปต์ Lua สามารถทำได้ ป้องกันไม่ให้เข้าถึงทรัพยากรของระบบหรือรันการดำเนินการที่เป็นอันตราย
ระดับการประเมินความเสี่ยง
- ความเสี่ยงวิกฤต: อินสแตนซ์ที่เปิดให้เข้าถึงผ่านอินเทอร์เน็ต + ไม่มีการตรวจสอบสิทธิ์
- ความเสี่ยงสูง: การเปิดให้เข้าถึงในเครือข่ายภายในโดยไม่มีการตรวจสอบสิทธิ์
- ความเสี่ยงต่ำกว่า: อินสแตนซ์ที่ได้รับการรักษาความปลอดภัยอย่างเหมาะสมด้วยการตรวจสอบสิทธิ์และการควบคุมเครือข่าย
- ความเสี่ยงน้อยที่สุด: การปรับใช้ที่ไม่ใช้สคริปต์ Lua ที่ส่งมาจากผู้ใช้
 |
|---|
| แผนภาพเครือข่ายที่แสดงช่องโหว่ของเซิร์ฟเวอร์ Redis ในโครงสร้างพื้นฐานทางไซเบอร์ |
ความกังวลเรื่องการเปิดเผยอย่างแพร่หลาย
แม้ว่าช่องโหว่เองอาจมีผลกระทบในทางปฏิบัติที่จำกัด แต่การวิจัยเผยให้เห็นสถิติที่น่ากังวลเกี่ยวกับแนวทางปฏิบัติในการปรับใช้ Redis มี Redis instance ประมาณ 330,000 ตัวที่เปิดเผยต่ออินเทอร์เน็ต โดยประมาณ 60,000 ตัวไม่มีการยืนยันตัวตนใดๆ เลย ตัวเลขเหล่านี้เน้นย้ำถึงปัญหาความปลอดภัยที่กว้างขึ้นนอกเหนือจากช่องโหว่เฉพาะนี้
ปัญหาเกิดขึ้นบางส่วนจากการกำหนดค่าเริ่มต้นและข้อผิดพลาดในการปรับใช้ทั่วไป บทช่วยสอน Docker และการตั้งค่าคอนเทนเนอร์หลายตัวผูกบริการกับอินเทอร์เฟซเครือข่ายทั้งหมดแทนที่จะจำกัดไว้ที่ localhost โดยไม่ได้ตั้งใจทำให้ฐานข้อมูลเปิดเผยต่อสาธารณะอินเทอร์เน็ต สิ่งนี้สร้างพายุที่สมบูรณ์แบบที่ช่องโหว่หลังการยืนยันตัวตนกลายเป็นสิ่งที่สามารถใช้ประโยชน์ได้โดยไม่ต้องยืนยันตัวตน
สстатิสติการเปิดเผย Redis
- อินสแตนซ์ที่เปิดเผยบนอินเทอร์เน็ตทั้งหมด: ~330,000
- อินสแตนซ์ที่ไม่มีการตรวจสอบสิทธิ์: ~60,000
- สภาพแวดล้อม Cloud ที่ใช้ Redis containers: 57%
- อายุของช่องโหว่: ~12 ปี (บั๊ก use-after-free)
 |
|---|
| แผนภูมิวงกลมแสดงเปอร์เซ็นต์ของสภาพแวดล้อม cloud ที่อาจได้รับผลกระทบจากช่องโหว่ของ Redis |
ภาพรวมใหญ่
ความขัดแย้งนี้สะท้อนถึงปัญหาที่ลึกซึ้งกว่าในการที่อุตสาหกรรมความปลอดภัยไซเบอร์สื่อสารความเสี่ยง แม้ว่าการวิจัยทางเทคนิคเบื้องหลังการค้นพบ CVE-2025-49844 จะดูมั่นคง แต่การให้คะแนนและการตั้งชื่อแบบเร้าอารมณ์ ( RediShell ) อาจไม่เป็นประโยชน์ต่อชุมชน ความไม่สอดคล้องระหว่างความรุนแรงเชิงทฤษฎีและผลกระทบในทางปฏิบัติสามารถนำไปสู่การจัดสรรทรัพยากรผิดและความเหนื่อยล้าด้านความปลอดภัย
บั๊กจะได้รับคะแนน CVSS ตามที่ทีมการตลาดของห้องปฏิบัติการวิจัยที่ค้นพบต้องการ มันเป็นเหมือนกระดานผีจริงๆ
ช่องโหว่ Redis ยังแสดงให้เห็นว่าสภาพแวดล้อมคลาวด์สมัยใหม่พึ่งพาเทคโนโลยีโอเพนซอร์สอย่างมาก แม้ว่าการพึ่งพานี้จะสร้างความเสี่ยงร่วมกัน แต่ก็ช่วยให้เกิดความพยายามด้านความปลอดภัยแบบร่วมมือกันเช่นโครงการ ZeroDayCloud ที่นักวิจัยกล่าวถึง
องค์กรที่ใช้ Redis ควรใช้แพตช์ที่มีอยู่อย่างแน่นอน โดยเฉพาะสำหรับ instance ที่เปิดเผยต่ออินเทอร์เน็ต อย่างไรก็ตาม การอภิปรายของชุมชนแสดงให้เห็นว่าแนวทางปฏิบัติในการปรับใช้ที่เหมาะสมและการควบคุมความปลอดภัยของเครือข่ายยังคงสำคัญกว่าการรีบแก้ไขช่องโหว่ทุกตัวที่มีคะแนน CVSS เต็ม บทเรียนที่แท้จริงอาจเป็นเรื่องการปรับปรุงการกำหนดค่าเริ่มต้นและคำแนะนำการปรับใช้มากกว่าการปฏิบัติต่อช่องโหว่ที่ได้คะแนนสูงทุกตัวเป็นภัยคุกคามสิ้นโลก
อ้างอิง: RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score