นักวิจัยจาก Tencent Zhuque Lab เปิดเผยช่องโหว่ Use-After-Free ในการจัดการ SCTP ASCONF (Address Configuration Change) ของ Linux Kernel ซึ่งตั้งชื่อว่า "SCTPhantom" (CVE-2026-64564) โดยช่องโหว่นี้ฝังอยู่ใน Kernel มาตั้งแต่เวอร์ชัน 2.6.25 เมื่อปี 2007 รวมอายุกว่า 18 ปี ผู้โจมตีที่มีสิทธิ์ผู้ใช้ทั่วไป (Local Unprivileged User) สามารถใช้ช่องโหว่นี้ยกระดับสิทธิ์เป็น Root และในบางกรณีสามารถ หลบหนีจาก Container สู่ Host ได้
รายละเอียดช่องโหว่
ช่องโหว่เกิดในฟังก์ชัน sctp_process_asconf() ซึ่งทำหน้าที่ประมวลผล ASCONF Chunk ในโปรโตคอล SCTP กลไกของช่องโหว่มีดังนี้:
- ฟังก์ชันนี้จะ Cache ตัวชี้ Transport ไว้ระหว่างการประมวลผล ASCONF Chunk
- หากผู้โจมตีส่งชุด ASCONF ที่ถูกสร้างขึ้นเป็นพิเศษ (Crafted Sequence) จนเกิด ความไม่ตรงกันระหว่าง Address ต้นทางของแพ็กเก็ตกับ ASCONF Address Parameter
- ผู้โจมตีสามารถทำให้ Transport ที่ถูก Cache ไว้ถูก Free ไปในขณะที่ Kernel ยังคงมีตัวชี้ที่ค้างอยู่ (Dangling Reference) ชี้ไปยังหน่วยความจำดังกล่าว
- เกิด Use-After-Free ที่ผู้โจมตีสามารถใช้ประโยชน์เพื่อยกระดับสิทธิ์ได้
ช่องโหว่นี้ได้รับคะแนน CVSS v4.0 ระดับ 8.5 (High) และได้รับการแก้ไขต้นทางแล้วผ่าน Commit 9b2854f86f0b โดยมีการ Backport แพตช์ไปยัง Stable Branch หลายเวอร์ชัน ได้แก่ 6.6.148, 6.12.101, 6.18.42 และ 7.1.6
ระบบที่ได้รับผลกระทบ
- ระบบ Linux แทบทุกระบบที่รัน Kernel ตั้งแต่เวอร์ชัน 2.6.25 (ปี 2007) เป็นต้นมา ที่ยังไม่ได้รับแพตช์
- สภาพแวดล้อม Container ที่มี Configuration บางลักษณะ มีความเสี่ยงถูกใช้เป็นช่องทางหลบหนีสู่ Host
- ระบบที่เปิดใช้งานโปรโตคอล SCTP ซึ่งมักพบในระบบ Telecom, Signaling และบางกรณีใน Container/Virtualization Stack
ผลกระทบที่อาจเกิดขึ้น
- ผู้โจมตีที่มีสิทธิ์ผู้ใช้ทั่วไปสามารถยกระดับเป็น Root ได้ โดยไม่ต้องอาศัยสิทธิ์พิเศษเริ่มต้น
- หลบหนีจาก Container สู่ Host ได้ในบางการตั้งค่า ซึ่งเป็นความเสี่ยงร้ายแรงสำหรับสภาพแวดล้อม Multi-Tenant
- ด้วยอายุของช่องโหว่ที่ยาวนานถึง 18 ปี ระบบจำนวนมากทั่วโลกมีแนวโน้มได้รับผลกระทบ เนื่องจากโค้ดที่มีปัญหาอยู่ใน Kernel มาอย่างยาวนานก่อนถูกค้นพบ
สิ่งที่องค์กรควรทำ
- ▸ ตรวจสอบเวอร์ชัน Linux Kernel ที่ใช้งานและอัปเดตเป็นเวอร์ชันที่มีแพตช์ (6.6.148, 6.12.101, 6.18.42, 7.1.6 หรือใหม่กว่า) โดยเร็ว
- ▸ สำหรับระบบที่ไม่จำเป็นต้องใช้ SCTP ให้พิจารณาปิดหรือ Blacklist โมดูล SCTP เป็นมาตรการชั่วคราวระหว่างรอการอัปเดต
- ▸ ตรวจสอบสภาพแวดล้อม Container ที่มีความเสี่ยงหลบหนีสู่ Host เป็นพิเศษ โดยเฉพาะระบบที่รัน Container จากหลายผู้เช่าบน Host เดียวกัน
- ▸ ติดตาม Distribution ของ Linux ที่องค์กรใช้งานว่าได้ Backport แพตช์นี้เข้าสู่เวอร์ชันที่ใช้งานแล้วหรือไม่
แนวทางลดความเสี่ยงระยะยาว
1. ปิดโมดูล Kernel ที่ไม่จำเป็นต่อการใช้งานจริง
เช่น SCTP หากไม่ได้ใช้งานโดยตรง เพื่อลดพื้นผิวการโจมตีจากช่องโหว่ในโปรโตคอลที่ไม่ได้ใช้
2. จัดกระบวนการ Patch Management สำหรับ Linux Kernel ให้ครอบคลุมทั้ง Host และ Container Runtime
เนื่องจากช่องโหว่ระดับนี้กระทบทั้งสองชั้นพร้อมกันได้
3. ใช้เครื่องมือตรวจสอบ Kernel Version อย่างสม่ำเสมอในสภาพแวดล้อม Container/Cloud
เนื่องจากระบบเหล่านี้มักมีจำนวน Host จำนวนมากที่ใช้ Kernel เวอร์ชันเดียวกัน หากมีช่องโหว่จะกระทบเป็นวงกว้าง
4. ทบทวนความเสี่ยงของ Legacy Code ใน Kernel ที่ไม่ได้ถูกตรวจสอบมานาน
ช่องโหว่อายุ 18 ปีนี้เป็นตัวอย่างว่าโค้ดที่ใช้งานมานานและดูเสถียรอาจยังมีปัญหาด้านความปลอดภัยที่ไม่เคยถูกค้นพบ
วิเคราะห์ในมุมมองจาก TXEC
SCTPhantom เป็นตัวอย่างที่ชัดเจนว่าอายุของโค้ดไม่ได้เป็นเครื่องยืนยันความปลอดภัย ช่องโหว่นี้ฝังอยู่ใน Linux Kernel มานานถึง 18 ปีโดยไม่มีใครตรวจพบ ก่อนที่นักวิจัยจะค้นพบผ่านการวิเคราะห์เชิงลึกในโปรโตคอลที่ไม่ได้ถูกใช้งานอย่างแพร่หลายเท่า TCP/UDP ทำให้ได้รับความสนใจตรวจสอบน้อยกว่า
TXEC มองว่าจุดที่น่ากังวลเป็นพิเศษคือความสามารถในการหลบหนีจาก Container สู่ Host ซึ่งกระทบโดยตรงต่อองค์กรที่ใช้สภาพแวดล้อม Cloud-Native หรือ Multi-Tenant Container Platform องค์กรควรตรวจสอบว่า Kernel ที่ใช้งานได้รับแพตช์นี้แล้วหรือไม่ และควรพิจารณาปิดโมดูล SCTP ในระบบที่ไม่จำเป็นต้องใช้งานจริง เพื่อลดพื้นผิวการโจมตีจากโปรโตคอลที่มักถูกมองข้ามในกระบวนการตรวจสอบความปลอดภัย
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: The Hacker News, Tencent Zhuque Lab, GBHackers, CyberSecurityNews ]