ทบทวนการโจมตี Spectre ระยะไกลบน Cloudflare Workers: บทเรียนการแยกผู้เช่าบนคลาวด์

ทีมวิจัยกลับมาทดสอบการโจมตี Spectre บนแพลตฟอร์ม Workers อีกครั้ง แล้วพบว่ายังดึงข้อมูลข้ามผู้เช่าได้ที่อัตราสูงสุด 12 บิตต่อวินาทีด้วยความแม่นยำ 99% บทความนี้สรุปว่าการโจมตีทำได้อย่างไร ทำไมมาตรการเดิมถึงไม่พอ และมาตรการใหม่ที่นำมาใช้บอกอะไรกับทีมที่ออกแบบระบบหลายผู้เช่า

Spectre คืออะไร และทำไมยังสำคัญในปี 2026

Spectre เป็นช่องโหว่ที่อาศัยการทำงานแบบคาดเดาล่วงหน้า (speculative execution) ของซีพียู ซึ่งเป็นกลไกที่ทำให้โปรเซสเซอร์สมัยใหม่เร็ว แต่ก็ทิ้งร่องรอยไว้ในแคชแม้ผลการคาดเดาจะถูกยกเลิกไปแล้ว ผู้โจมตีจึงวัดเวลาเข้าถึงหน่วยความจำเพื่ออนุมานข้อมูลที่ไม่ควรเห็นได้ ปัญหาคือช่องโหว่ระดับสถาปัตยกรรมแบบนี้ไม่สามารถแพตช์ให้หายขาดด้วยซอฟต์แวร์ ทำได้เพียงลดความเป็นไปได้ลงเรื่อย ๆ

เรื่องนี้สำคัญเป็นพิเศษกับแพลตฟอร์มที่รันโค้ดของผู้เช่าหลายรายในโปรเซสเดียวกันเพื่อความเร็วและต้นทุน ซึ่ง Cloudflare Workers ใช้ V8 isolate แยกฮีปของแต่ละผู้เช่าในระดับภาษา ไม่ใช่ระดับระบบปฏิบัติการ

นักวิจัยทำได้ถึงไหน

ผลการประเมินรอบล่าสุดในช่วงปี 2024 ถึง 2025 พบว่าสามารถดึงข้อมูลออกจากแพลตฟอร์มได้อย่างเสถียรที่อัตราสูงสุด 12 บิตต่อวินาที ด้วยความแม่นยำราว 99% และสาธิตได้จริงในสภาพแวดล้อมโปรดักชันด้วยการดึงโทเคน JWT ออกจาก Worker ของเหยื่อ เทียบกับงานวิจัยเมื่อปี 2021 ที่ทำได้เพียงราว 120 บิตต่อชั่วโมง ถือว่าเป็นการยกระดับที่ชัดเจนมาก

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

ทำไมมาตรการเดิมถึงไม่พอ

Cloudflare มีมาตรการหลายชั้นอยู่แล้ว ทั้งการแช่แข็งตัวจับเวลาไม่ให้เดินระหว่างประมวลผล การไม่มี SharedArrayBuffer และมัลติเธรด รวมถึงระบบ Dynamic Process Isolation ที่คอยเฝ้าตัวนับประสิทธิภาพของฮาร์ดแวร์เพื่อแยกสคริปต์ที่ดูน่าสงสัยออกไปรันในโปรเซสของตัวเอง

แต่การประเมินรอบนี้พบช่องว่างสองจุด จุดแรกคือระบบจะแยกสคริปต์ออกไปหลังการเรียกใช้จบลงแล้ว ขณะที่การเชื่อมต่อ WebSocket ผ่าน Durable Objects สามารถรีเซ็ตขีดจำกัดเวลาซีพียูได้ทุกครั้งที่มีข้อความเข้ามา ทำให้การทำงานยืดยาวเป็นชั่วโมงและโจมตีจนสำเร็จก่อนที่การแยกโปรเซสจะถูกกระตุ้น จุดที่สองคือการตรวจจับใช้การเทียบสัดส่วนการเดาสาขาผิดกับการเข้าถึง iTLB ซึ่งทราฟฟิกจาก WebSocket ทำให้ตัวหารสูงขึ้นจนพฤติกรรมโจมตีดูเหมือนงานที่ใช้ I/O หนักตามปกติ

มาตรการใหม่ที่นำมาใช้

มาตรการชุดใหม่มีสามส่วน ส่วนแรกคือ V8 Sandbox ที่ตัดพอยน์เตอร์ขนาด 64 บิตออกจากพื้นที่ฮีปส่วนใหญ่ ทำให้ gadget แบบที่ใช้ในงานวิจัยนี้ใช้การได้ยากขึ้น ส่วนที่สองคือ Memory Protection Keys ที่เริ่มใช้ตั้งแต่กันยายน 2025 ซึ่งเป็นการแยกหน่วยความจำด้วยฮาร์ดแวร์ภายในโปรเซสเดียวกัน ทำให้แม้การอ่านแบบคาดเดาจะสำเร็จก็ยังข้ามขอบเขตของ isolate อื่นไม่ได้ ส่วนที่สามคือการปรับตรรกะการตรวจจับให้มองการทำงานที่ยืดยาวและงานที่ใช้ I/O หนักเป็นสัญญาณที่ต้องสงสัย ไม่ใช่สัญญาณรบกวนพื้นหลัง

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

สิ่งที่ทีมไทยควรนำไปใช้

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

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