สรุปสั้น

โปรแกรมธรรมดาบน Linux ที่ไม่มีสิทธิ์พิเศษใดๆ สามารถจับจังหวะยิงอินเทอร์รัปต์ของฮาร์ดแวร์ให้ตกลงพอดีในช่องว่างระหว่างตอนที่ตัวประมวลผลล้างข้อมูลในตัวทำนายกิ่ง (branch predictor) กับตอนที่เคอร์เนลจะใช้งานตัวทำนายนั้น ผลคือสามารถป้อนข้อมูลหลอกกลับเข้าไปใหม่ได้หลังจากมาตรการป้องกันทำงานเสร็จไปแล้ว เท่ากับว่าเกราะที่ระบบเพิ่งสร้างขึ้นถูกทำลายทิ้งก่อนถูกใช้จริง

นักวิจัยจาก MIT CSAIL คือนาย Daniël Trujillo และนางสาว Mengjia Yan ตั้งชื่อเทคนิคนี้ว่า INTERRUPT INJECTION โดยบนเครื่อง AMD Zen 2 ที่รัน Linux 6.14 พร้อมเปิดมาตรการกัน Spectre v2 แบบค่าเริ่มต้นครบทุกตัว โค้ดสาธิตของทั้งคู่ดูดข้อมูลจากหน่วยความจำเคอร์เนลออกมาได้ตามใจชอบที่อัตรา 5.47 ไบต์ต่อวินาที ด้วยความแม่นยำ 91.97% ซึ่งเพียงพอที่จะค้นหาและอ่านไฟล์ /etc/shadow ที่เก็บค่าแฮชของรหัสผ่านในระบบได้สำเร็จ 5 ครั้งจากการทดลอง 10 ครั้ง

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

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 6 สิงหาคม 2569 ว่า การแก้ไขปัญหานี้อยู่ในเคอร์เนล Linux แล้วผ่าน commit ชื่อ “x86/bugs: Make Safe-RET robust against interrupt injection” ลงวันที่ 2 มิถุนายน เขียนโดยนาย Borislav Petkov และพัฒนาร่วมกับนาย David Kaplan ซึ่งทั้งคู่เป็นวิศวกรของ AMD โดยคำอธิบายใน commit บรรยายการโจมตีด้วยถ้อยคำเดียวกับที่นักวิจัยใช้ คือการยิงอินเทอร์รัปต์เข้าไปขณะที่ Safe-RET กำลังทำงาน “สามารถทำให้ลำดับการคืนค่าที่ปลอดภัยเป็นหมันได้ ซึ่งอาจนำไปสู่การรั่วไหลของข้อมูลผ่านการประมวลผลเชิงคาดเดา” ตัวแพตช์แก้ด้วยการจัดสถานะของรีจิสเตอร์ให้เหมือนกับว่าลำดับ Safe-RET ทำงานจบแล้ว และหลีกเลี่ยงการรันคำสั่ง RET หลังอินเทอร์รัปต์คืนกลับมา ซึ่งเป็นหนึ่งในสองแนวทางที่งานวิจัยเสนอไว้

ฝั่ง AMD เผยแพร่ประกาศ AMD-SB-7061 เมื่อวันที่ 6 สิงหาคม ในชื่อ “Safe RET Interrupt Vulnerability” ระบุว่าตัวประมวลผลตั้งแต่ Zen 1 ถึง Zen 4 ได้รับผลกระทบ โดยสรุปว่าผู้โจมตีที่รันโค้ดบนระบบที่ได้รับผลกระทบ “สามารถยิงอินเทอร์รัปต์ในจังหวะที่แม่นยำเพื่อรบกวน Safe RET” ซึ่ง “อาจทำให้การป้องกันนั้นอ่อนแอลงและอาจส่งผลให้เกิดการเปิดเผยข้อมูล” พร้อมเสริมว่าปัญหานี้ “ดูเหมือนจะเกี่ยวข้องกับการนำมาตรการ Safe RET ไปใช้งานในฝั่ง Linux” ประกาศฉบับนี้ให้เครดิตนาย Trujillo และระบุว่าพฤติกรรมดังกล่าวถูกสาธิตบน Zen 1 และ Zen 2 ส่วน Zen 3 และ Zen 4 เป็นการอนุมานแต่ยังไม่ได้สาธิต ขณะที่งานวิจัยรายงานว่า AMD ทดสอบเฉพาะ Zen 2 และ Zen 4 เท่านั้น

จุดที่เป็นปัญหาในทางปฏิบัติคือ หัวข้อ “Affected Products and Mitigation” ในประกาศของ AMD ระบุเพียงรายชื่อตัวประมวลผลเท่านั้น ไม่มีการอ้างถึงแพตช์ ไม่มีเวอร์ชันเคอร์เนล และไม่มีหมายเลข CVE อีกทั้งทั้งประกาศของ AMD และประกาศของ MIT ต่างก็ไม่ได้ชี้ไปที่ commit ในเคอร์เนล ผลคือผู้ดูแลระบบต้องรู้ชื่อหัวข้อของ commit เองจึงจะตรวจได้ว่าเครื่องหนึ่งๆ มีแพตช์นี้แล้วหรือยัง ยิ่งไปกว่านั้น เคอร์เนลรายงานสถานะ SRSO ไว้ที่ /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow แต่เอกสารที่นิยามความหมายของค่าในไฟล์นั้นกลับไม่ได้กล่าวถึงอินเทอร์รัปต์เลย ณ วันที่ The Hacker News ตรวจสอบเมื่อวันที่ 6 สิงหาคม

ทั้งคู่นำเสนอผลงานนี้ในงาน Black Hat USA และเตรียมนำเสนอในงาน USENIX Security ที่เมืองบัลติมอร์ในสัปดาห์ถัดไป โดย ณ วันที่ 6 สิงหาคม ที่เก็บโค้ดสาธิตที่ระบุไว้ในงานวิจัยยังไม่เปิดเป็นสาธารณะ ส่วน The Hacker News ระบุว่าได้ติดต่อ AMD, Intel และ Arm เพื่อขอความเห็นแล้ว

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

มาตรการป้องกัน Spectre v2 ทุกตัวทำงานบนหลักการเดียวกัน คือล้างหรือแยกสถานะของตัวทำนายกิ่งออกจากกัน เพื่อไม่ให้ข้อมูลที่ผู้โจมตีเคยป้อนไว้ก่อนหน้าไปชี้นำการทำนายกิ่งในเคอร์เนล ฝั่ง Intel ทำตอนเข้าสู่เคอร์เนลด้วย eIBRS ร่วมกับลูปล้าง branch history buffer หรือใช้ตัวควบคุม BHI_DIS_S ขึ้นกับรุ่นของตัวประมวลผล ส่วน AMD ทำทันทีก่อนการคืนค่าจากเคอร์เนลทุกครั้งด้วย saferet

จุดอ่อนร่วมกันคือกลไกทั้งหมดตั้งสมมติฐานว่าจะไม่มีอะไรที่เป็นอันตรายทำงานคั่นระหว่างสองจังหวะนั้น นาย Trujillo และนางสาว Yan เรียกช่องโหว่ประเภทนี้ว่า TONTOU ซึ่งย่อมาจาก Time-of-Neutralization to Time-of-Use ล้อกับสภาวะแข่งขันแบบ TOCTOU ที่คุ้นเคยกันในโลกซอฟต์แวร์ อินเทอร์รัปต์ทำลายสมมติฐานนี้ เพราะมันเกิดขึ้นได้แทบทุกจุด และ Linux ยอมให้ผู้ใช้ทั่วไปตั้งเวลาให้มันทำงานได้ละเอียดถึงระดับนาโนวินาที ข้อสรุปเชิงหลักการคือ ถ้าการจัดการอินเทอร์รัปต์แทรกอยู่ระหว่างการล้างกับการใช้งานได้ เส้นทางการคืนค่าจากอินเทอร์รัปต์ก็ต้องถือเป็นส่วนหนึ่งของการป้องกัน Spectre v2 ด้วย แม้มาตรการนั้นจะถูกออกแบบมาเพื่อจังหวะเข้าหรือออกจากเคอร์เนลก็ตาม

บน Zen 2 ช่องว่างที่ว่านี้กว้างเพียงสองคำสั่ง หรือ 6 ไบต์ นักวิจัยเพิ่มโอกาสยิงเข้าเป้าด้วยการไล่ 6 ไบต์นั้นออกจากแคช L1 และ L2 โดยใช้ hyperthread ที่อยู่คู่กันเพื่อทำให้ช่วงนั้นช้าลง และเลือกใช้ syscall ชื่อ write ซึ่งทำให้ควบคุมรีจิสเตอร์ได้สองตัว ผลคืออินเทอร์รัปต์ตกลงในช่องว่างได้ 5% ถึง 12% ของความพยายาม และประมาณ 2% ในกรณีที่ควบคุมรีจิสเตอร์ทั้งสองตัวได้ด้วย เมื่อเข้าไปอยู่ในช่องนั้นแล้ว ตัวจัดการอินเทอร์รัปต์เองก็กลายเป็นเครื่องมือฝึกตัวทำนาย โดยใช้ร่วมกับช่องโหว่ Inception (CVE-2023-20569) เพื่อเติม return stack buffer ด้วยเป้าหมายที่ผู้โจมตีเลือกไว้ ซึ่งน่าสังเกตว่า Inception คือช่องโหว่ของ AMD เมื่อปี 2566 ที่ saferet ถูกสร้างขึ้นมาเพื่อป้องกันโดยเฉพาะ

ผลการทดสอบพบการทำนายผิดพลาดในโค้ดของเคอร์เนลบนเครื่อง 3 ใน 4 เครื่องที่ทดสอบ ด้วยอัตราความสำเร็จ 0.75% บน Zen 2, 0.22% บน Intel Arrow Lake และ 0.037% บน Cascade Lake Refresh ส่วน Zen 4 ไม่พบเลยในการทดสอบดังกล่าว และยังไม่มีการสาธิตการดูดข้อมูลแบบครบวงจรบนซีพียู Intel ซึ่งผู้โจมตีจะต้องมีชิ้นส่วนโค้ดที่ใช้เปิดเผยข้อมูลอยู่ในเคอร์เนลอยู่แล้วด้วย

นักวิจัยไม่ได้มองว่านั่นเป็นอุปสรรค โดยระบุกับ The Hacker News ว่าการทำนายผิดพลาดเป็น “เงื่อนไขที่จำเป็นแต่ยังไม่เพียงพอสำหรับการโจมตีแบบ Spectre” และเนื่องจากงานวิจัยก่อนหน้านี้แสดงให้เห็นแล้วว่ามีชิ้นส่วนโค้ดที่ใช้เปิดเผยข้อมูลอยู่ในเคอร์เนล “เราจึงเชื่อว่าการโจมตีแบบครบวงจรเป็นไปได้บน Intel เช่นกัน หากนำ Interrupt Injection ของเราไปประกอบกับงานเหล่านั้น” ด้าน Intel จ่ายเงินรางวัลพิเศษให้ตามโครงการ bug bounty แต่ตามที่ระบุในงานวิจัย บริษัท “ไม่ถือว่าจำเป็นต้องมีมาตรการแก้ไข” โดยให้เหตุผลว่าความเป็นไปได้ในการโจมตี “ขึ้นอยู่กับหลายปัจจัย” และเทคนิคนี้อยู่ในขอบเขตของคำแนะนำที่มีอยู่แล้ว อย่างไรก็ตาม The Hacker News ตรวจสอบคำแนะนำที่ว่า คือ INTEL-SA-00598 ฉบับปัจจุบันซึ่งอัปเดตล่าสุดเมื่อเดือนพฤษภาคม 2568 แล้วไม่พบการกล่าวถึงอินเทอร์รัปต์อยู่ในนั้นเลย

ผลกระทบ

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

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

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

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

คำแนะนำ

สำหรับผู้ดูแลระบบ Linux บนซีพียู AMD ให้ตรวจสอบว่าเคอร์เนลที่ใช้อยู่มี commit “x86/bugs: Make Safe-RET robust against interrupt injection” แล้วหรือยัง ซึ่งเป็นวิธีเดียวที่ตรวจได้แน่ชัดในตอนนี้ เนื่องจากยังไม่มีหมายเลข CVE และเวอร์ชันอ้างอิงให้ใช้ ในทางปฏิบัติแนวทางที่ปลอดภัยที่สุดคืออัปเดตเคอร์เนลเป็นรุ่นที่ใหม่กว่าเดือนมิถุนายน 2569 ตามช่องทางอัปเดตปกติของดิสโทรที่ใช้

ผู้ให้บริการคลาวด์และผู้ดูแลระบบที่แชร์ทรัพยากรควรจัดลำดับความสำคัญของการอัปเดตนี้สูงกว่าองค์กรทั่วไป เพราะโมเดลภัยคุกคามของการโจมตีนี้ตรงกับสภาพแวดล้อมแบบ multi-tenant พอดี

พิจารณาปิด SMT หรือ hyperthreading บนเครื่องที่รันงานของผู้ใช้ที่ไม่น่าเชื่อถือร่วมกัน เพราะนักวิจัยอาศัย hyperthread ที่อยู่คู่กันในการไล่ข้อมูลออกจากแคชเพื่อขยายช่องว่างเวลา มาตรการนี้แลกมาด้วยประสิทธิภาพที่ลดลง จึงควรชั่งน้ำหนักตามลักษณะงาน

อย่าใช้ค่าใน /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow เป็นข้อสรุปว่าเครื่องปลอดภัยจากเทคนิคนี้ เพราะเอกสารที่นิยามค่าดังกล่าวยังไม่ได้ครอบคลุมกรณีอินเทอร์รัปต์ และสำหรับผู้ใช้ซีพียู Intel ให้ติดตามท่าทีของบริษัทต่อไป เนื่องจากปัจจุบันยังไม่มีมาตรการแก้ไขที่ออกมาโดยเฉพาะ

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