พบช่องโหว่ระดับ Critical ในไลบรารี isolated-vm ซึ่งเป็นเครื่องมือ Sandboxing ยอดนิยมสำหรับ Node.js ที่ใช้แยกการทำงานของ JavaScript ที่ไม่น่าเชื่อถือออกจาก Host Process เป็นปัญหา Type Confusion ร่วมกับ Time-of-Check to Time-of-Use (TOCTOU) ในฟังก์ชัน ExternalCopy เปิดทางให้โค้ด JavaScript ที่รันอยู่ภายใน Sandbox สามารถหลุดออกมา (Sandbox Escape) และยึดครอง Control Flow ของ Host Process ได้ ความเสี่ยงนี้ส่งผลกระทบรุนแรงเป็นพิเศษต่อระบบ Multi-tenant, AI Agent Platform และ Workflow Automation ที่รันโค้ดจากผู้ใช้หรือ AI Model โดยตรง
รายละเอียดช่องโหว่
ช่องโหว่นี้ถูกติดตามในชื่อ GHSA-864f-rcv7-6rh4 (รอการกำหนดหมายเลข CVE) ส่งผลกระทบต่อ isolated-vm ทุกเวอร์ชันก่อนหน้า 7.0.1 และ 6.2.0 โดยทีมพัฒนาได้เผยแพร่แพตช์แก้ไขเมื่อวันที่ 8 สิงหาคม 2569
isolated-vm ใช้กลไกของ V8 Isolate ในการแยก JavaScript Environment ออกจากกัน โดยแต่ละ Sandbox จะมี Heap, Built-in Object และ Object Graph เป็นของตัวเอง ป้องกันไม่ให้โค้ดใน Sandbox เข้าถึง Object ของ Host ได้โดยตรง เว้นแต่ Host จะเปิดเผยความสามารถบางอย่างให้โดยเจตนา เช่นผ่าน ivm.Reference
นักวิจัยจาก Endor Labs พบว่าตัว V8 Isolation Primitive เองไม่ได้มีปัญหา แต่ช่องโหว่อยู่ที่โค้ด C++ Native Binding ที่รับผิดชอบการถ่ายโอนข้อมูลข้ามขอบเขต Isolation โดยเฉพาะฟังก์ชัน ExternalCopy ที่ใช้ Option transferList สำหรับถ่ายโอน ArrayBuffer แบบ Transfer แทนการ Copy เพื่อเพิ่มประสิทธิภาพกับ Buffer ขนาดใหญ่
จุดบกพร่องอยู่ที่ขั้นตอนการประมวลผล transferList ซึ่งมีการวนซ้ำ (Iterate) 2 รอบ: รอบแรกตรวจสอบว่าทุก Entry เป็น ArrayBuffer จริง ส่วนรอบที่สองทำการถ่ายโอน Entry เดียวกันโดยไม่ตรวจสอบชนิดข้อมูลซ้ำ ผู้โจมตีสามารถใช้ JavaScript Getter ที่มีสถานะ (Stateful Getter) เพื่อคืนค่า ArrayBuffer จริงในการอ่านครั้งแรก แต่คืนค่าอื่นที่ไม่ใช่ ArrayBuffer (เช่น Integer หรือ String) ในการอ่านครั้งที่สอง ทำให้โค้ด Native ตีความค่าที่ไม่คาดคิดนั้นเป็น ArrayBuffer ผ่านการแปลงชนิดข้อมูลที่ไม่มีการตรวจสอบ (Unchecked Conversion) เกิดเป็น Type Confusion และช่องโหว่ TOCTOU ที่ Host Process สามารถ Dereference หน่วยความจำที่ผู้โจมตีควบคุมได้
จาก Denial-of-Service สู่ Control-flow Hijacking
ผลกระทบขั้นต่ำสุดของช่องโหว่นี้คือทำให้ Host Process ล่ม (Crash) เกิดเป็น Denial-of-Service แต่นักวิจัยสามารถสาธิตการยกระดับผลกระทบไปถึงขั้น Hijack Control Flow ของ Host Process ได้สำเร็จ โดยเริ่มต้นจากการมี ivm.Reference เพียงตัวเดียวที่ Host มอบให้ Sandbox ตามปกติ ซึ่งเป็นรูปแบบที่ใช้กันทั่วไปในการให้ความสามารถจำกัดแก่โค้ดใน Sandbox ผู้โจมตีสามารถเรียก ExternalCopy Constructor ผ่าน Reference ที่มีอยู่ และสร้าง transferList ที่เป็นอันตรายได้ทั้งหมดจากภายใน Sandbox เอง โดยไม่จำเป็นต้องมีความสามารถเพิ่มเติมใด ๆ
ระบบที่ได้รับผลกระทบ
- isolated-vm ทุกเวอร์ชันก่อนหน้า 7.0.1 และ 6.2.0
- แพลตฟอร์ม Multi-tenant ที่ใช้ isolated-vm แยกการทำงานของ Tenant แต่ละราย
- AI Agent Platform และระบบที่รันโค้ด JavaScript ที่ AI Model สร้างขึ้น โดยไม่ผ่านการตรวจสอบจากมนุษย์
- Workflow Automation Tool และ User-script Runner ที่อนุญาตให้ผู้ใช้อัปโหลดหรือรันสคริปต์ของตนเอง
- บริการที่รันโค้ด JavaScript ของลูกค้า (Customer-provided Code) ภายใน Sandbox เพื่อความปลอดภัย
ผลกระทบที่อาจเกิดขึ้น
- การหลุดออกจาก Sandbox (Sandbox Escape) ที่นำไปสู่ Remote Code Execution บน Host ทำลายสมมติฐานพื้นฐานของระบบที่ออกแบบมาให้แยกโค้ดที่ไม่น่าเชื่อถือออกจากกัน
- ความเสี่ยงสูงเป็นพิเศษต่อระบบ AI Agent ที่ให้ AI Model สร้างและรันโค้ดโดยอัตโนมัติ เนื่องจาก Sandbox มักถูกใช้เป็นกลไกควบคุมความเสี่ยง (Governance Control) หลักในสถาปัตยกรรมเหล่านี้ หากถูกหลุด กลไกควบคุมทั้งหมดจะล้มเหลวไปด้วย
- ผลกระทบต่อระบบ Multi-tenant ที่ลูกค้าหลายรายใช้ Infrastructure ร่วมกัน ผู้โจมตีที่เป็น Tenant รายหนึ่งอาจสามารถเข้าถึงข้อมูลหรือขัดขวางการทำงานของ Tenant รายอื่นผ่าน Host Process เดียวกันได้
- แม้ Exploit จะต้องอาศัยเงื่อนไขเฉพาะ (Getter ที่มีสถานะ และ Timing ที่แม่นยำ) แต่ก็มีการสาธิตความเป็นไปได้จริงแล้วโดยนักวิจัย ทำให้ความเสี่ยงไม่ใช่เพียงทฤษฎี
สิ่งที่องค์กรควรทำ
- อัปเกรด isolated-vm เป็นเวอร์ชัน 7.0.1 หรือ 6.2.0 ขึ้นไปโดยทันที สำหรับทุกระบบที่ใช้ไลบรารีนี้
- ตรวจสอบ Dependency Tree ขององค์กรว่ามีการใช้ isolated-vm ทางตรงหรือทางอ้อมหรือไม่ โดยเฉพาะในผลิตภัณฑ์ AI Agent, Workflow Automation หรือ SaaS Multi-tenant
- ทบทวนความสามารถ (Capability) ที่เปิดเผยให้กับโค้ดใน Sandbox ลดจำนวน
ivm.Referenceและฟังก์ชันที่ Sandbox เข้าถึงได้ให้น้อยที่สุดเท่าที่จำเป็น - ตรวจสอบ Native Binding Layer อื่น ๆ ที่เกี่ยวข้องกับการถ่ายโอนข้อมูลข้าม Isolation Boundary เนื่องจากช่องโหว่นี้แสดงให้เห็นว่า Isolation Primitive ที่แข็งแกร่งยังคงถูกบ่อนทำลายได้ด้วยโค้ด Glue ที่ไม่ปลอดภัย
แนวทางลดความเสี่ยงระยะยาว
1. อย่าพึ่งพา Sandbox เป็นกลไกป้องกันชั้นเดียว (Defense-in-Depth)
สำหรับระบบที่รันโค้ดไม่น่าเชื่อถือ ควรมีการควบคุมเพิ่มเติมระดับ OS/Container เช่น gVisor, Firecracker MicroVM หรือ Seccomp เสริมจาก V8 Isolate
2. จัดทำกระบวนการตรวจสอบ Dependency ด้าน Security อย่างต่อเนื่อง
โดยเฉพาะไลบรารีที่ทำหน้าที่ด้าน Isolation หรือ Security-critical ซึ่งช่องโหว่มีผลกระทบสูงกว่าไลบรารีทั่วไป
3. จำกัดสิทธิ์ของ Host Process ที่รัน Sandbox ให้น้อยที่สุด (Principle of Least Privilege)
เพื่อลดผลกระทบหาก Sandbox ถูกหลุดสำเร็จ ไม่ให้ผู้โจมตีได้สิทธิ์สูงเกินความจำเป็นบน Host
4. ทบทวนสถาปัตยกรรม AI Agent และ Automation ที่รันโค้ดอัตโนมัติ
ให้มีมนุษย์ตรวจสอบ (Human-in-the-loop) หรือ Guardrail เพิ่มเติมสำหรับ Action ที่มีความเสี่ยงสูง แทนการพึ่งพา Sandbox เพียงอย่างเดียว
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่ใน isolated-vm สะท้อนความเสี่ยงเชิงโครงสร้างที่สำคัญของยุค AI Agent ที่กำลังเติบโตอย่างรวดเร็ว องค์กรจำนวนมากเริ่มนำระบบที่ให้ AI Model สร้างและรันโค้ดโดยอัตโนมัติมาใช้งานจริง โดยพึ่งพา Sandbox เป็นกลไกควบคุมความเสี่ยงหลักเพียงชั้นเดียว กรณีนี้แสดงให้เห็นชัดเจนว่าแม้ Isolation Primitive ระดับสูงอย่าง V8 Isolate จะออกแบบมาอย่างแข็งแกร่ง แต่โค้ด Glue ที่เชื่อมต่อระหว่าง Sandbox กับ Host ก็ยังคงเป็นจุดอ่อนที่สามารถถูกโจมตีได้
TXEC มองว่าองค์กรที่กำลังพัฒนาหรือใช้งานผลิตภัณฑ์ AI Agent, Workflow Automation หรือ SaaS แบบ Multi-tenant ควรทบทวนสถาปัตยกรรมความปลอดภัยของตนใหม่ โดยไม่ควรมองว่า "มี Sandbox แล้วปลอดภัย" แต่ควรมี Defense-in-Depth หลายชั้นควบคู่กันไป เนื่องจากแนวโน้มที่ AI กำลังเร่งการค้นพบช่องโหว่ในโครงสร้างพื้นฐานประเภทนี้ให้เร็วขึ้นเรื่อย ๆ
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: The Hacker News, Cyber Security News, SecurityWeek, Endor Labs, GitHub Security Advisory ]