สรุปสั้น

ช่องโหว่ประเภท use-after-free ในโค้ดเครือข่าย SCTP ของเคอร์เนล Linux สามารถถูกใช้ยกระดับสิทธิ์เป็น root บนเครื่องได้เต็มรูปแบบ และนักวิจัยของ Tencent ระบุว่าใช้มันหนีออกจากคอนเทนเนอร์ไปถึงเครื่องที่อยู่ข้างใต้ได้ด้วย โดยข้อบกพร่องนี้มีอยู่ในเคอร์เนลมาตั้งแต่ปี 2551 หรือกว่า 18 ปี

ช่องโหว่ถูกติดตามในรหัส CVE-2026-64564 และถูกตั้งชื่อว่า SCTPhantom โดยผู้ค้นพบ เปิดเผยต่อสาธารณะเมื่อวันที่ 6 สิงหาคม 2569 สองวันหลังทีม CVE ของเคอร์เนลกำหนดรหัสให้ แพตช์ออกไปก่อนหน้านั้นแล้วในเคอร์เนลเสถียรเวอร์ชัน 7.1.6, 6.18.42, 6.12.101 และ 6.6.148 ที่ปล่อยเมื่อวันที่ 3 สิงหาคม

ข้อจำกัดสำคัญที่ทำให้ระดับความเสี่ยงไม่สูงเท่าช่องโหว่ระยะไกลคือ นี่เป็นการโจมตีจากในเครื่อง ไม่ใช่จากระยะไกล และต้องมี SCTP เข้าถึงได้บนเป้าหมาย ในสภาพแวดล้อมที่เงื่อนไขเหล่านั้นเป็นจริง ห้องปฏิบัติการ Tencent Zhuque Lab รายงานว่าได้สิทธิ์ root บนเคอร์เนลที่ทดสอบของ Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 และ OpenCloudOS ขณะที่ ณ เวลาที่รายงานยังไม่มีโค้ดโจมตีสาธารณะปรากฏ และ The Hacker News ตรวจสอบแล้วไม่พบช่องโหว่นี้ในบัญชี KEV ของ CISA ณ วันที่ 7 สิงหาคม 2569

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 7 สิงหาคม 2569 ว่า SCTP หรือ Stream Control Transmission Protocol เป็นโปรโตคอลชั้นขนส่งที่ออกแบบให้การเชื่อมต่อหนึ่งวิ่งผ่านเส้นทางเครือข่ายหลายเส้นพร้อมกันได้ และมีฟีเจอร์ประกอบชื่อ dynamic address reconfiguration ที่เปิดให้ฝ่ายตรงข้ามเพิ่มหรือถอดที่อยู่เหล่านั้นระหว่างที่การเชื่อมต่อยังทำงานอยู่ ซึ่งเป็นจุดที่ข้อบกพร่องนี้อาศัย

18-year-old Linux SCTP flaw could let local users gain root and escape containers

ข้อบกพร่องนี้สืบย้อนกลับไปถึงเคอร์เนล Linux 2.6.25 ในปี 2551 และติดอยู่ในทุกเคอร์เนลที่ปล่อยออกมานับจากนั้น การค้นพบครั้งนี้ Tencent ให้เครดิตกับ Corvus AI ซึ่งเป็นสายงานวิจัยแบบหลายเอเจนต์ที่บริษัทสร้างขึ้นสำหรับงานเคอร์เนลโดยเฉพาะ ทำให้ SCTPhantom เป็นรายการล่าสุดในชุดช่องโหว่เคอร์เนลที่หลับอยู่มานานแล้วถูกขุดขึ้นมาด้วยความช่วยเหลือของเครื่องจักรในปีนี้ ต่อจาก GhostLock เมื่อเดือนกรกฎาคม

น่าสนใจว่าช่องโหว่นี้ถูกเปิดเผยวันเดียวกับ Zapscape ซึ่งเป็นช่องโหว่หนีออกจาก KVM ที่ไม่เกี่ยวข้องกัน และเคอร์เนลเสถียรทั้งสี่เวอร์ชันเดียวกันก็บรรจุแพตช์ของทั้งสองรายการไว้ด้วยกัน

ประเด็นที่ต้องระบุให้ชัดคือคะแนนความรุนแรงยังไม่ลงตัว Tencent ให้คะแนนไว้ที่ 8.5 ตามเกณฑ์ CVSS v4.0 แต่ NVD ยังไม่กำหนดทั้งคะแนนและการจัดประเภทจุดอ่อน ณ วันที่ 7 สิงหาคม ขณะที่ประกาศของ openKylin ที่ครอบคลุมข้อบกพร่องตัวเดียวกัน ระบุผลกระทบไว้เพียงแค่ระดับเคอร์เนลแพนิกและการปฏิเสธการให้บริการเท่านั้น ซึ่งต่างจากที่ Tencent อ้างอย่างมีนัยสำคัญ

รายละเอียดช่องโหว่

แก่นของข้อบกพร่องคือความสับสนเรื่องอัตลักษณ์ กล่าวคือเคอร์เนลตรวจสอบคำขอลบที่อยู่โดยเทียบกับที่อยู่ต้นทางของแพ็กเก็ต แต่กลับลงมือกระทำต่อเส้นทางที่มันเลือกมาจากที่อยู่คนละตัวซึ่งอยู่ข้างในข้อความนั้น

ตามประกาศของเคอร์เนลเอง ข้อความหนึ่งข้อความสามารถบรรจุที่อยู่หนึ่งตัว ตามด้วยคำสั่งลบที่อยู่ตัวเดียวกันนั้น แล้วตามด้วยคำสั่งลบแบบไวลด์การ์ดอีกที ลำดับดังกล่าวทำให้เส้นทางถูกคืนหน่วยความจำไปก่อน แล้วตัวชี้ที่ตายแล้วถูกนำกลับมาใช้ซ้ำ ทิ้งให้การเชื่อมต่อชี้ไปยังหน่วยความจำที่เคอร์เนลปล่อยคืนไปแล้ว ซึ่งคือลักษณะของ use-after-free โดยตรง แพตช์แก้ด้วยการปฏิเสธคำสั่งลบที่เล็งไปยังเส้นทางเดียวกับที่ข้อความนั้นกำลังถูกประมวลผลอยู่

สำหรับข้ออ้างเรื่องการหนีออกจากคอนเทนเนอร์ ต้องระบุให้ชัดว่ามาจากการทดสอบของห้องแล็บ Tencent เอง ในบทความ ห้องแล็บระบุว่าโค้ดโจมตีเวอร์ชันแรกของตนต้องเปิด sysctl ทั้ง net.sctp.addip_enable และ net.sctp.addip_noauth_enable ซึ่งทำให้ดูเหมือนว่าสิทธิ์ CAP_NET_ADMIN เป็นเงื่อนไขจำเป็น แต่ภายหลังพบเส้นทางที่ไม่ต้องแตะค่าทั้งสองเลย โดยเปิดใช้ฟีเจอร์ในระดับซ็อกเก็ตแทน ห้องแล็บระบุว่าการทดสอบหนีคอนเทนเนอร์ใช้โปรไฟล์ seccomp ค่าเริ่มต้น และไม่ได้ให้ทั้ง CAP_NET_ADMIN และ CAP_SYS_ADMIN โดยนับได้ว่าสำเร็จถึง root บนโฮสต์ 6 จาก 8 ครั้ง

อย่างไรก็ตาม ยังไม่มีใครนอกห้องแล็บทำซ้ำผลลัพธ์เหล่านั้นได้ และบทความไม่ได้ระบุว่าทดสอบกับ container runtime ตัวใด ห้องแล็บเองก็ระบุว่าการเข้าถึงซ็อกเก็ต โปรไฟล์ seccomp และนโยบาย user namespace ล้วนทำให้ระดับความเสี่ยงเปลี่ยนไปได้ นอกจากนี้ยังมีช่องโหว่ use-after-free จากตัวชี้เส้นทางค้างอีกตัวในโค้ดชุดเดียวกัน ที่เพิ่งถูกแพตช์เมื่อวันที่ 6 สิงหาคม ซึ่งเป็นวันหลังจากเคอร์เนลเสถียรทั้งสี่เวอร์ชันปล่อยออกไปแล้ว ดังนั้นเคอร์เนลชุดนั้นจึงไม่ได้บรรจุแพตช์ตัวหลังนี้ไว้

ผลกระทบ

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

จุดที่มีน้ำหนักที่สุดคือมิติของคอนเทนเนอร์ ถ้าข้ออ้างของ Tencent ถูกต้อง แปลว่าโค้ดที่รันอยู่ในคอนเทนเนอร์โดยไม่มีสิทธิ์พิเศษใด ๆ และยังใช้โปรไฟล์ seccomp ค่าเริ่มต้น ก็สามารถทะลุออกไปควบคุมโฮสต์ได้ ซึ่งกระทบสมมติฐานพื้นฐานของการแบ่งแยกภาระงานหลายผู้เช่าบนโฮสต์เดียวกันโดยตรง สภาพแวดล้อมที่รันโค้ดจากผู้ใช้ภายนอก เช่น ระบบ CI/CD ที่รันงานของนักพัฒนา หรือแพลตฟอร์มที่ให้ลูกค้าส่งคอนเทนเนอร์ของตัวเองเข้ามารัน คือกลุ่มที่ควรให้ความสำคัญสูงสุด

ในทางกลับกัน ต้องระบุข้อจำกัดของหลักฐานให้ครบ คือข้ออ้างเรื่องการหนีคอนเทนเนอร์มีแหล่งเดียวคือห้องแล็บผู้ค้นพบ ยังไม่มีการทำซ้ำโดยบุคคลที่สาม ไม่ระบุ runtime ที่ใช้ทดสอบ ยังไม่มีโค้ดโจมตีสาธารณะ ไม่มีรายงานการโจมตีจริง ไม่อยู่ในบัญชี KEV และประกาศของดิสโทรหนึ่งประเมินผลกระทบไว้แค่ระดับ DoS เท่านั้น สิ่งเหล่านี้ไม่ได้แปลว่าข้ออ้างผิด แต่แปลว่ายังไม่ควรถือเป็นข้อเท็จจริงที่ยืนยันแล้ว

คำแนะนำ

สิ่งแรกคืออัปเดตเคอร์เนล โดยเป้าหมายคือเวอร์ชันเสถียร 7.1.6, 6.18.42, 6.12.101 หรือ 6.6.148 ขึ้นไป แต่ต้องระวังว่า ตัวเลขเวอร์ชันเคอร์เนลอย่างเดียวบอกไม่ได้ว่าปลอดภัยแล้วหรือยัง เพราะผู้จัดจำหน่ายมักย้อนแพตช์กลับไปในเวอร์ชันเดิมโดยไม่ขยับเลขขึ้นตามต้นน้ำ วิธีที่ถูกต้องคือตรวจกับตัวติดตามความปลอดภัยของดิสโทรที่ใช้อยู่โดยตรง

ในสภาพแวดล้อมที่ไม่จำเป็นต้องใช้ SCTP ซึ่งครอบคลุมระบบส่วนใหญ่ วิธีที่ตัดปัญหาได้เด็ดขาดที่สุดคือบล็อกไม่ให้โมดูลถูกโหลด ซึ่งทำให้พื้นผิวการโจมตีหายไปทั้งหมด ไม่ใช่แค่ลดลง ผู้ดูแลควรตรวจก่อนว่ามีบริการใดในระบบพึ่งพา SCTP อยู่จริงหรือไม่ ก่อนดำเนินการ

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

สุดท้าย ควรติดตามการปรับปรุงในบัญชี NVD และประกาศของดิสโทรต่อไป เพราะทั้งคะแนนความรุนแรงและการจัดประเภทยังไม่ลงตัว รวมถึงติดตามแพตช์ของช่องโหว่ตัวที่สองในโค้ดชุดเดียวกันที่ออกวันที่ 6 สิงหาคม ซึ่งไม่ได้อยู่ในเคอร์เนลเสถียรชุดวันที่ 3 สิงหาคม

แหล่งอ้างอิง