- Branch Privilege Injection เป็นช่องโหว่ที่ทำให้สามารถข้ามการป้องกันฮาร์ดแวร์ตระกูล Spectre-BTI ซึ่งคงอยู่มาราว 6 ปี ได้อีกครั้ง ผ่าน race condition ของตัวทำนายสาขาใน CPU ของ Intel
- แกนหลักของการโจมตีคือ การอัปเดตตัวทำนายสาขา ถูกประมวลผลแบบอะซิงโครนัสกับลำดับคำสั่ง และในบางเงื่อนไขอาจสะท้อนผลช้าลงหลายสิบถึงหลายร้อยไซเคิล
- หากยังมีการอัปเดตที่ล่าช้าค้างอยู่ระหว่างการสลับสิทธิ์หรือระหว่างการรัน IBPB การอัปเดตนั้นอาจถูกผูกเข้ากับ security domain ที่ไม่ถูกต้องในภายหลัง ทำให้การรับประกันความปลอดภัยของ eIBRS และ IBPB ถูกทำลาย
- นักวิจัยสาธิตการโจมตีแบบ end-to-end บน Intel Raptor Lake รุ่นที่ 13 โดยเปิดใช้มาตรการบรรเทาเริ่มต้นทั้งหมดบน Ubuntu 24.04 และสามารถรั่วไหล หน่วยความจำตามอำเภอใจ ได้ที่ 5.6KiB/s
- อัปเดตไมโครโค้ด ของ Intel สามารถบล็อก primitive สำหรับตรวจจับช่องโหว่ได้ในการประเมินบน Alder Lake และมีโอเวอร์เฮดสูงสุด 2.7%
เงื่อนไขที่ทำให้ Branch Privilege Injection เกิดขึ้นได้
- Branch Privilege Injection เป็นการโจมตีแบบ branch target injection หรือก็คือการทำให้ Spectre-BTI กลับมาใช้ได้ผลอีกครั้งในสภาพแวดล้อมของ Intel
- มาตรการบรรเทาระดับฮาร์ดแวร์ของ Intel ป้องกันการโจมตีประเภทนี้มาได้ราว 6 ปี แต่การวิจัยครั้งนี้แสดงให้เห็นว่า race condition ใน CPU ของ Intel สามารถสั่นคลอนการป้องกันนั้นได้
- การโจมตีอาศัยข้อสังเกต 2 ประการ
- ตัวทำนายสาขาของโปรเซสเซอร์ Intel ถูก อัปเดตแบบอะซิงโครนัส กับลำดับคำสั่ง
- ในบางเงื่อนไข การอัปเดตอาจล่าช้าไปหลายสิบหรือหลายร้อยไซเคิล
- การอัปเดตแบบอะซิงโครนัสเองไม่ใช่ช่องโหว่ แต่เป็นคุณสมบัติของระบบ
- ระหว่างการทำงานที่สำคัญต่อความปลอดภัย มี การซิงโครไนซ์ระหว่างตัวทำนายสาขากับลำดับคำสั่งไม่เพียงพอ
- ระหว่างการสลับจาก user mode ไป kernel หรือจาก guest ไป hypervisor การอัปเดตอาจยังดำเนินอยู่
- แม้ขณะรัน IBPB ก็อาจยังมีการอัปเดตที่ค้างอยู่ระหว่างประมวลผล
- หากการอัปเดตเหล่านี้มาถึงหลังการสลับสิทธิ์ มันจะถูกผูกกับโหมดสิทธิ์ใหม่แทนที่จะเป็นสิทธิ์เดิม
- ตัวทำนายสาขาของโปรเซสเซอร์ Intel ถูก อัปเดตแบบอะซิงโครนัส กับลำดับคำสั่ง
- ช่องโหว่ประเภทนี้มีชื่อว่า Branch Predictor Race Conditions
มาตรการบรรเทาที่ถูกทำลายและขอบเขตผลกระทบ
- eIBRS เป็นมาตรการบรรเทา Spectre-BTI ที่ Intel นำมาใช้กับโปรเซสเซอร์ทั้งหมดตั้งแต่ Coffee Lake Refresh รุ่นที่ 9 เป็นต้นมา
- เป้าหมายคือแยกการทำนาย indirect branch ตามแต่ละ security domain
- ถูกออกแบบให้เชื่อมแต่ละการทำนายเข้ากับโดเมนที่มันถูกสร้างขึ้น และหลังจากนั้นจะใช้เฉพาะการทำนายของโดเมนปัจจุบัน
- หากมีการอัปเดตค้างอยู่ระหว่างการสลับสิทธิ์แล้วถูกผูกเข้ากับ security domain ใหม่ ความเชื่อมโยงนี้ก็อาจถูกบิดเบือนได้
- IBPB เป็นกลไกที่ใช้แยก sandbox หรือ virtual machine ที่ไม่ไว้วางใจกันภายใน hardware security domain เดียวกัน
- มันมีความสามารถในการทำให้การทำนาย indirect branch ทั้งหมดเป็นโมฆะ
- การอัปเดตที่ยังค้างประมวลผลจะไม่ถูกล้างโดย IBPB จึงอาจถูกเก็บลงในตัวทำนายสาขาได้แม้หลังการทำให้เป็นโมฆะแล้ว
- ขอบเขตผลกระทบแตกต่างกันไปตามรุ่นและสถาปัตยกรรม
- โปรเซสเซอร์ Intel ทั้งหมดตั้งแต่ Coffee Lake Refresh รุ่นที่ 9 เป็นต้นมาได้รับผลกระทบจาก Branch Privilege Injection
- พบการทำนายที่ใช้ข้าม IBPB ย้อนกลับไปถึง Kaby Lake รุ่นที่ 7
- ไม่พบปัญหานี้ในระบบ AMD และ ARM ที่ทำการประเมิน
- แม้การโจมตีแบบ proof-of-concept จะถูกสร้างสำหรับ Linux แต่เนื่องจากปัญหาหลักอยู่ที่ฮาร์ดแวร์ ระบบปฏิบัติการใดก็ตามที่รันบนฮาร์ดแวร์ที่ได้รับผลกระทบก็ได้รับผลกระทบเช่นกัน
มาตรการบรรเทา ต้นทุนด้านประสิทธิภาพ และข้อมูลเผยแพร่
- แนะนำให้ติดตั้ง ระบบปฏิบัติการและ BIOS เวอร์ชันล่าสุด
- Intel ได้พัฒนาอัปเดตไมโครโค้ดสำหรับโปรเซสเซอร์ที่ได้รับผลกระทบ และนักวิจัยได้ประเมินมันบน Alder Lake
- มาตรการบรรเทาระดับไมโครโค้ดสามารถบล็อก primitive สำหรับตรวจจับช่องโหว่ได้
- บน Alder Lake มีโอเวอร์เฮดสูงสุด 2.7%
- มีการประเมินมาตรการบรรเทาทางซอฟต์แวร์ทางเลือกด้วย
- บน Coffee Lake Refresh มีโอเวอร์เฮด 1.6%
- บน Rocket Lake มีโอเวอร์เฮด 8.3%
- รายละเอียดทางเทคนิคเพิ่มเติมดูได้จากบทความวิจัย
- งานวิจัย Branch Privilege Injection มีกำหนดนำเสนอที่ USENIX Security 2025 และมีกำหนดบรรยายที่ Black Hat USA 2025
- ซอร์สโค้ดของการโจมตีและการทดลองเผยแพร่ไว้บน github
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
บล็อกโพสต์ของนักวิจัย: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
เปเปอร์: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
ในสถานการณ์โจมตี สุดท้ายแล้วการที่ข้อมูลในหน่วยความจำ CPU ทั้งหมดจะตกไปอยู่ในมือคนผิดก็เป็นเพียงเรื่องของเวลา
เป็นบทความที่ดี สรุปคือ การอัปเดต branch predictor อาจถูกเลื่อนไปอีกนานหลังจากคำสั่ง branch retire แล้ว
ถ้าไม่เป็นแบบนั้น การ retire คำสั่ง branch ก็คงใช้เวลานานขึ้น จึงสมเหตุสมผล คำสั่ง dispatch serialization ดูเหมือนจะไม่หยุด pipeline เพราะมีการอัปเดตสถานะ predictor ที่ค้างอยู่ด้วย และนี่ก็เป็นเรื่องธรรมชาติ เพราะได้แยก “การ commit ผลลัพธ์ของคำสั่ง branch” กับ “การ commit ผลการทำนาย” ไว้แล้ว
คำสั่งเปลี่ยนสิทธิ์ก็ไม่หยุด pipeline เพราะมีการอัปเดตที่ค้างอยู่เช่นกัน ซึ่งจะสมเหตุสมผลก็ต่อเมื่อสามารถรับประกันได้ว่าระดับสิทธิ์ตอนสร้างการทำนายและตอน commit นั้นสอดคล้องกัน มิฉะนั้นการทำนายที่โค้ดในระดับสิทธิ์หนึ่งสร้างขึ้น อาจถูก commit เข้าไปในสถานะที่ถูกใช้งานในอีกระดับสิทธิ์หนึ่งได้
บางทีนี่อาจเป็นปัญหาที่ยาก เพราะใน pipeline ระดับสิทธิ์ปัจจุบัน อาจไม่ใช่ค่าเดียวที่ชัดเจน
ดีใจที่เห็นชื่อ Kaveh Razavi เมื่อก่อนเขาเคยสอนที่ Vrije Universiteit Amsterdam และวิชา Hardware Security ก็ลงลึกเรื่องแบบนี้ได้ยอดเยี่ยมมาก
อยากรู้ว่ามีวิดีโอบันทึกการสอนหรือโน้ตอย่างเป็นทางการอยู่บนออนไลน์ไหม
มีใครรู้ไหมว่าสิ่งนี้เกี่ยวข้องกับการโจมตี Training Solo ที่เพิ่งเผยแพร่ออกมาอย่างไร? https://www.vusec.net/projects/training-solo/
Training Solo เข้าไปใน kernel แล้วเปลี่ยนระดับสิทธิ์ จากนั้นใช้ “การเรียนรู้ด้วยตัวเอง” เพื่อทำให้ branch ถูกทำนายผิดไปยัง disclosure gadget และทำให้หน่วยความจำรั่วไหล
Branch predictor race conditions คือการเข้าไปใน kernel ตอนที่การอัปเดต branch predictor ที่เรียนรู้ไว้ยังประมวลผลไม่เสร็จ ทำให้การอัปเดตนั้นถูกผูกกับระดับสิทธิ์ที่ผิด จากนั้นใช้สิ่งนี้เพื่อเบี่ยง branch ของ kernel ไปยัง disclosure gadget และทำให้หน่วยความจำรั่วไหล
ถ้า branch predictor ของ CPU สามารถใช้ข้อมูลสำหรับตรวจสอบขอบเขตบัฟเฟอร์และระดับสิทธิ์ของโค้ดได้โดยตรง ปัญหาแบบนี้คงป้องกันได้ง่ายกว่านี้มาก
แต่คงไม่เกิดขึ้นจนกว่าเราจะดึง
void*ออกจากมือเย็นชืดของโปรแกรมเมอร์ C และเสริมข้อมูลสำคัญให้ pointer ก่อนถ้าจะทำสิ่งที่ต้องการ ต้องมีสถาปัตยกรรมฮาร์ดแวร์ที่ให้ทุก load/store ต้องผ่าน “address แบบเสริมข้อมูล” บางชนิดที่เก็บข้อมูลขอบเขตไว้
กล่าวคือเท่ากับเรียกร้อง 80286 segmentation ซึ่งเคยมีอยู่แล้วและไม่ได้ทำสิ่งที่ต้องการได้ เหตุผลคือ segment descriptor เหล่านั้นก็ยังต้องถูกซอฟต์แวร์โหลดให้ถูกต้องอยู่ดี จากมุมมองของซอฟต์แวร์ สุดท้ายมันก็เป็น “แค่ pointer” จึงยังเปราะบางต่อความผิดพลาดแบบเดิม
ในกรณี speculative execution หากจะใช้ช่องโหว่นั้นทำอะไรจริง ๆ ต้องมีการเตรียมการล่วงหน้ามากจนน่าขัน วิธีที่ใช้งานได้จริงแทบจะมีแค่อย่างเดียว คือเข้าถึงเครื่องนั้นโดยตรงและรันโค้ดระดับต่ำ การทำให้ความลับตามอำเภอใจรั่วไหลด้วยโค้ด JS ที่รันในเบราว์เซอร์อย่างเดียวนั้นไม่ใช่กรณีนี้
ถ้าเป็นระบบที่มีคุณค่าพอให้หน่วยงานเอกชนเฉพาะทางหรือหน่วยงานที่รัฐสนับสนุนลงทุนวิจัยและทำการเจาะจงเป้าหมาย ก็ควรมีระบบที่ป้องกันไม่ให้รันโค้ดใด ๆ ที่ไม่ได้รับอนุญาตได้ตั้งแต่แรก
ส่วนตัวผมรู้สึกได้จริงถึงประสิทธิภาพที่ดีขึ้น จึงปิด mitigation ทั้งหมดไว้
คำแนะนำด้านความปลอดภัยของ Intel: https://www.intel.com/content/www/us/en/security-center/advi...
สงสัยว่าฮาร์ดแวร์ของ AMD มีช่องโหว่คล้าย ๆ กันหรือไม่ speculative execution ดูเหมือนเป็นช่องโหว่ที่แพตช์ได้ยากมากในพื้นที่โปรเซสเซอร์ที่ใช้ร่วมกัน เลยสงสัยว่า AMD หลีกเลี่ยงมาได้อย่างไร
ระบุว่าไม่พบปัญหาในระบบ AMD และ ARM ที่ประเมิน
ที่มา: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
ช่องโหว่เฉพาะตัวนี้ดูเหมือนจะเป็นของ Intel เท่านั้น คล้าย Meltdown แต่ AMD ก็เคยเสี่ยงต่อ Spectre ดั้งเดิมเหมือนกัน
แต่ เอนจิน speculative execution มีความซับซ้อน จึงมีบั๊กและช่องโหว่แพร่หลายมาก
มีความเป็นไปได้สูงว่า AMD และ ARM ก็มีบั๊กคล้ายกัน ลองคิดดูว่าบั๊กเหล่านี้ใน Intel ไม่ถูกพบมานานแค่ไหนก็พอ
น่าเสียดายที่ทางแก้จริง ๆ คือการยอมรับว่าเราไม่สามารถแยกโค้ดที่รันบนระบบสมัยใหม่ออกจากกันได้ ซึ่งอาจเป็นเรื่องร้ายแรงต่อโมเดลธุรกิจของบริษัทที่ร่ำรวยมากบางแห่ง
ไม่ใช่วิธีแก้แบบเดียวกับปัญหาที่อาจเกิดในซอฟต์แวร์หรือ?
เขาบอกว่า “หากต้องการปิดช่องโหว่แบบนี้ จำเป็นต้องมีอัปเดตพิเศษของ ไมโครโค้ด โปรเซสเซอร์ ซึ่งทำได้ผ่าน BIOS หรือการอัปเดตระบบปฏิบัติการ ดังนั้นควรถูกติดตั้งบนพีซีผ่านหนึ่งในอัปเดตสะสมล่าสุดของ Windows” แล้วทำไมถึงพูดถึงแต่ Windows? ผู้ใช้ Linux ล่ะ?
ดิสโทรต่าง ๆ ถูกตั้งค่าให้นำจากที่นี่ไปแจกจ่ายอัตโนมัติ
แต่ไม่ค่อยแน่ใจว่าต้องดูอะไรเพื่อยืนยันว่ามาตรการบรรเทาเฉพาะตัวนี้ถูกรวมเข้าไปแล้วหรือยัง
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL) มานานแล้วแต่ Intel ต้องเผยแพร่ไฟล์ไมโครโค้ดที่จำเป็นเพื่อให้ผู้ดูแลดิสโทรอัปเดตแพ็กเกจได้ จากนั้นมันจะถูกรวมอยู่ในการอัปเดตระบบ
สงสัยว่า Intel ยังมีทางฟื้นตัวไหม ในตลาดไม่มีผลิตภัณฑ์ที่ดูดีพอ งานวิจัยและพัฒนาใช้เวลานาน และธุรกิจฟาวน์ดรีก็ล้าหลังคู่แข่งจนยังเป็นแหล่งขาดทุนต่อเนื่อง
แถม x86 ยังถูกฮาร์ดแวร์ ARM เบียดออกไปเรื่อย ๆ และตอนนี้ RISC-V จากจีนก็กำลังโตขึ้น แน่นอนว่ายังมีมุมมองด้านเซมิคอนดักเตอร์ของสหรัฐฯ ด้วย โดยเฉพาะหลังจากเจอปัญหาช่วงโควิด สหรัฐฯ จะปล่อยให้ผู้ผลิตหลักอย่าง Intel ล้มลงจริงหรือ?
สถานการณ์ไม่ดีนักก็จริง แต่ความตื่นตูมแบบเรียกยอดอ่านนั้นน่าขำ
เกมเมอร์เป็นเพียงไม่กี่เปอร์เซ็นต์ของผู้ใช้ผลิตภัณฑ์ Intel แต่กลับเป็นกลุ่มที่ถูกพูดถึงมากที่สุด คำสั่งซื้อจากดาต้าเซ็นเตอร์เพียงหนึ่งหรือสองรายการก็ใหญ่กว่าซีพียูเกมมิงทั้งหมดที่ Intel ขายได้ในหนึ่งปีแล้ว Intel ยังยืนหยัดได้ดีใน ตลาดดาต้าเซ็นเตอร์
นอกจากนี้ Intel ยังครองตลาดโน้ตบุ๊กสำหรับองค์กรอยู่ และตลาดนี้ก็ใหญ่กว่าตลาดเกมเมอร์ค่อนข้างมากเช่นกัน
ปีที่แล้ว Arm มีส่วนแบ่งตลาดดาต้าเซ็นเตอร์เพียง 15% และในตลาด Windows ก็ยังไม่ได้คืบหน้าอย่างมีนัยสำคัญ
แยกจากตัวผลิตภัณฑ์แล้ว จากมุมมองผู้ถือหุ้น/ธุรกิจ ผมมองว่าผลประกอบการทางการเงินช่วงนี้สะท้อนผลิตภัณฑ์ปลายทางน้อยลงเรื่อย ๆ เลยพยายามคิดแยกกัน แต่ผมคิดว่า Intel ใกล้เคียงกับ ใหญ่เกินกว่าจะล้ม
อยากเช็กว่าผมเข้าใจถูกไหม ณ ตอนนี้ระบบปฏิบัติการหลักทั้งหมดมีแพตช์ที่บรรเทาปัญหานี้หรือใช้ ไมโครโค้ด ที่เกี่ยวข้องแล้วใช่ไหม?