การศึกษาเผยรายละเอียดการโจมตีจริงที่สามารถหลบเลี่ยงการป้องกัน MTE ใน Chrome และ Linux

สารบัญลิงก์

บทคัดย่อ

1. บทนำ

2. ความเป็นมา

• ส่วนขยายการแท็กหน่วยความจำ
• การโจมตีด้วยการประมวลผลแบบคาดเดา

3. โมเดลภัยคุกคาม

4. การค้นหา Tag Leakage Gadgets

• เทมเพลต Tag Leakage
• Tag Leakage Fuzzing

5. TIKTAG Gadgets

• TIKTAG-v1: การใช้ประโยชน์จาก Speculation Shrinkage
• TIKTAG-v2: การใช้ประโยชน์จาก Store-to-Load Forwarding

6. การโจมตีในโลกจริง

6.1. การโจมตี Chrome

7. การประเมินผล

8. งานวิจัยที่เกี่ยวข้อง

9. บทสรุปและเอกสารอ้างอิง

\

การโจมตีในโลกจริง

เพื่อแสดงให้เห็นถึงความสามารถในการใช้ประโยชน์จาก TIKTAG gadgets ในการป้องกันที่อาศัย MTE ส่วนนี้พัฒนาการโจมตีในโลกจริงสองรูปแบบต่อ Chrome และ Linux kernel (รูปที่ 9) มีความท้าทายหลายประการในการเปิดตัวการโจมตีในโลกจริงโดยใช้ TIKTAG gadgets ประการแรก TIKTAG gadgets ควรถูกดำเนินการในพื้นที่หน่วยความจำเป้าหมาย ซึ่งต้องการให้ผู้โจมตีสร้างหรือค้นหา gadgets จากระบบเป้าหมาย ประการที่สอง ผู้โจมตีควรควบคุมและสังเกตสถานะแคชเพื่อรั่วไหลผลการตรวจสอบแท็ก ต่อไปนี้เราจะแสดงการโจมตีในโลกจริงโดยใช้ TIKTAG gadgets บนระบบจริงสองระบบ: เบราว์เซอร์ Google Chrome (§6.1) และ Linux kernel (§6.2) และหารือเกี่ยวกับกลยุทธ์การป้องกัน

\ 6.1. การโจมตี Chrome

เบราว์เซอร์ เว็บเบราว์เซอร์เป็นพื้นที่โจมตีหลักสำหรับการโจมตีผ่านเว็บ เนื่องจากประมวลผลเนื้อหาเว็บที่ไม่น่าเชื่อถือ เช่น JavaScript และ HTML เราจะสรุปภาพรวมของโมเดลภัยคุกคาม (§6.1.1) และให้ TIKTAG gadget ที่สร้างขึ้นในเอ็นจิน V8 JavaScript (§6.1.2) จากนั้นเราจะแสดงให้เห็นประสิทธิผลของ TIKTAG gadgets ในการใช้ประโยชน์จากเบราว์เซอร์ (§6.1.3) และหารือเกี่ยวกับกลยุทธ์การป้องกัน (§6.1.4)

\ ==6.1.1. โมเดลภัยคุกคาม== เราปฏิบัติตามโมเดลภัยคุกคามทั่วไปของการโจมตีเบราว์เซอร์ Chrome โดยผู้โจมตีมีเป้าหมายที่จะใช้ประโยชน์จากช่องโหว่การทำลายหน่วยความจำในกระบวนการเรนเดอร์ เราสมมติว่าผู้ใช้ที่เป็นเหยื่อเข้าชมเว็บไซต์ที่ผู้โจมตีควบคุม ซึ่งให้บริการหน้าเว็บที่เป็นอันตราย หน้าเว็บรวมถึง HTML และ JavaScript ที่สร้างขึ้นเพื่อใช้ประโยชน์จากช่องโหว่การทำลายหน่วยความจำในกระบวนการเรนเดอร์ของเหยื่อ เราสมมติว่าเทคนิคการป้องกันที่ทันสมัยของ Chrome ทั้งหมดถูกนำมาใช้ รวมถึง ASLR [18], CFI [15], site isolation [53] และ V8 sandbox [56] นอกจากนี้ ในฐานะการป้องกันที่เป็นอิสระ เราสมมติว่ากระบวนการเรนเดอร์เปิดใช้งานการแท็ก MTE แบบสุ่มใน PartitionAlloc [2]

\ ==6.1.2. การสร้าง TIKTAG Gadget== ในสภาพแวดล้อม V8 JavaScript, TIKTAG-v2 ถูกสร้างขึ้นสำเร็จและรั่วไหลแท็ก MTE ของที่อยู่หน่วยความจำใดๆ อย่างไรก็ตาม เราไม่พบ TIKTAG-v1 gadget ที่สามารถสร้างได้ เนื่องจากข้อจำกัดด้านเวลาที่แน่นหนาระหว่าง BR และ CHECK ไม่สามารถทำได้ในเทคนิค speculative V8 sandbox escape ของเรา (§A)

V8 TikTag-v2 Gadget. รูปที่ 8 คือ TIKTAG-v2 gadget ที่สร้างขึ้นในเอ็นจิน V8 JavaScript และโค้ด pseudo-C หลังจากการคอมไพล์ JIT ด้วย gadget นี้ ผู้โจมตีสามารถเรียนรู้ว่าแท็กที่เดา Tg ตรงกับแท็ก Tm ที่กำหนดให้กับ target_addr หรือไม่ ผู้โจมตีเตรียมอาร์เรย์สามตัว slow, victim, probe และค่า idx slow เป็น Unit8Array ที่มีความยาว 64 และถูกเข้าถึงใน BR เพื่อกระตุ้นการคาดการณ์สาขาผิดพลาด victim เป็น Float64Array ที่มีความยาว 64 ซึ่งถูกเข้าถึงเพื่อกระตุ้น store-to-load forwarding probe เป็น Uint8Array ที่มีความยาว 512 และถูกเข้าถึงใน

\ TEST เพื่อรั่วไหลผลการตรวจสอบแท็ก ค่า idx ประเภท Number ถูกใช้ในการเข้าถึงนอกขอบเขตของ victim ค่า idx ถูกเลือกเพื่อให้ victim[idx] ชี้ไปที่ target_addr ด้วยแท็กที่เดา Tg (เช่น (Tg«56)|target_addr) เพื่อเข้าถึง target_addr นอก V8 sandbox แบบคาดเดา เราใช้ประโยชน์จากเทคนิค speculative V8 sandbox escape ที่เราค้นพบระหว่างการวิจัย ซึ่งเราอธิบายรายละเอียดใน §A บรรทัดที่ 8 ของรูปที่ 8a คือบลอก BR ของ TIKTAG-v2 gadget ที่กระตุ้นการคาดการณ์สาขาผิดพลาดด้วย slow[0]

\ บรรทัดที่ 12-13 คือบลอก CHECK ซึ่งดำเนินการ store-to-load forwarding ด้วย victim[idx] เข้าถึง target_addr ด้วยแท็กที่เดา Tg เมื่อโค้ดนี้ถูกคอมไพล์ด้วย JIT (รูปที่ 8b) การตรวจสอบขอบเขตจะถูกดำเนินการ โดยเปรียบเทียบ idx กับ victim.length หาก idx เป็นดัชนีนอกขอบเขต โค้ดจะส่งคืน undefined แต่หากฟิลด์ victim.length ใช้เวลานานในการโหลด CPU จะดำเนินการคำสั่ง store และ load ต่อไปแบบคาดเดา

\ หลังจากนั้น บรรทัดที่ 17 ใช้งานบลอก TEST ซึ่งเข้าถึง probe ด้วยค่าที่ส่งต่อ val เป็นดัชนี อีกครั้ง การตรวจสอบขอบเขตของ val กับความยาวของ probe จะถูกนำหน้า แต่การตรวจสอบนี้สำเร็จเนื่องจาก PROBE_OFFSET มีขนาดเล็กกว่าความยาวของอาร์เรย์ probe ผลลัพธ์คือ probe[PROBE_OFFSET] ถูกแคชเฉพาะเมื่อ store-to-load forwarding สำเร็จ ซึ่งเป็นกรณีที่ Tg ตรงกับ Tm

\ ==6.1.3. การโจมตีบายพาส MTE ของ Chrome== รูปที่ 9a แสดงภาพรวมของการโจมตีบายพาส MTE บนเบราว์เซอร์ Chrome ด้วย primitive การรั่วไหลแท็กแบบกำหนดเองของ TIKTAG gadgets เราสมมติว่ามีช่องโหว่ buffer overflow ในกระบวนการเรนเดอร์ โดยการใช้ประโยชน์จากช่องโหว่ชั่วคราว (เช่น use-after-free) นั้นเหมือนกันเป็นส่วนใหญ่ ช่องโหว่ทำให้พอยน์เตอร์ (เช่น vuln_ptr) ล้นไปยังออบเจ็กต์ที่มีช่องโหว่ (เช่น objvuln) ทำให้ออบเจ็กต์ที่อยู่ติดกัน (เช่น objtarget) เสียหาย

\ ด้วยการบังคับใช้ MTE ของ PartitionAlloc ออบเจ็กต์สองตัวมีแท็กที่แตกต่างกันด้วยความน่าจะเป็น 14/15 เพื่อหลีกเลี่ยงการยกข้อยกเว้น ผู้โจมตีจำเป็นต้องแน่ใจว่าแท็กของ objvuln และ objtarget เหมือนกัน TIKTAG-v2 สามารถใช้เพื่อรั่วไหลแท็กของ objvuln ( 1 ) และ objtarget ( 2 ) หากแท็กที่รั่วไหลทั้งสองเหมือนกัน ผู้โจมตีจะใช้ประโยชน์จากช่องโหว่ ซึ่งจะไม่ยกข้อผิดพลาดการตรวจสอบแท็ก ( 3 ) มิฉะนั้น ผู้โจมตีจะปลดปล่อยและจัดสรร objtarget ใหม่และกลับไปยังขั้นตอนแรกจนกว่าแท็กจะตรงกัน

\ ==การกระตุ้น Cache Side-Channel== เพื่อใช้ประโยชน์จาก TIKTAG gadget ได้สำเร็จ ผู้โจมตีจำเป็นต้องตอบสนองข้อกำหนดต่อไปนี้:

i) branch training,

ii) cache control และ

iii) cache measurement ข้อกำหนดทั้งสามสามารถตอบสนองได้ใน JavaScript

ประการแรก ผู้โจมตีสามารถฝึกตัวคาดการณ์สาขาโดยรัน gadget ด้วย slow[0] ที่ไม่เป็นศูนย์และ idx ที่อยู่ในขอบเขต และกระตุ้นการคาดการณ์สาขาผิดพลาดใน BR ด้วยค่าศูนย์ใน slow[0] และ idx ที่นอกขอบเขต

ประการที่สอง ผู้โจมตีสามารถไล่แคชไลน์ของ slow[0], victim.length และ probe[PROBE_OFFSET] ด้วยเทคนิคการไล่แคช JavaScript [8, 21, 70]

ประการที่สาม ผู้โจมตีสามารถวัดสถานะแคชของ probe[PROBE_OFFSET] ด้วยตัวจับเวลาความละเอียดสูงที่อิงจาก SharedArrayBuffer [16, 58]

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

\ ==6.1.4. การป้องกัน== เพื่อลดการโจมตีบายพาส MTE ที่อิงจาก TIKTAG gadget ในกระบวนการเรนเดอร์ของเบราว์เซอร์ สามารถใช้การป้องกันต่อไปนี้:

i) Speculative execution-aware sandbox: เพื่อหยุดผู้โจมตีจากการเปิดตัวการโจมตีที่อิงจาก TIKTAG จากสภาพแวดล้อม sandbox เช่น V8 sandbox, sandbox สามารถเสริมความแข็งแกร่งโดยป้องกันการเข้าถึงหน่วยความจำแบบคาดเดาใดๆ นอกภูมิภาคหน่วยความจำของ sandbox แม้ว่าเว็บเบราว์เซอร์สมัยใหม่จะใช้ sandbox เพื่อแยกเนื้อหาเว็บที่ไม่น่าเชื่อถือออกจากเรนเดอร์ พวกเขามักมองข้ามเส้นทางคาดเดา

\ ตัวอย่างเช่น Chrome V8 sandbox [56] และ Safari Webkit sandbox [1] ไม่ได้ไกล่เกลี่ยเส้นทางคาดเดาอย่างสมบูรณ์ [27] โดยอิงจากเทคนิคการบีบอัดพอยน์เตอร์ปัจจุบัน [64] เส้นทางคาดเดาสามารถจำกัดไว้ที่ภูมิภาค sandbox โดยการปิดบังบิตสูงของพอยน์เตอร์

\ ii) Speculation barrier: ตามที่แนะนำใน §5 การวาง speculation barrier หลัง BR สำหรับ TIKTAG gadgets ที่มีศักยภาพสามารถป้องกันการโจมตีการรั่วไหลแท็กแบบคาดเดา อย่างไรก็ตาม การป้องกันนี้อาจไม่สามารถใช้ได้ในสภาพแวดล้อมเบราว์เซอร์ที่มีความสำคัญต่อประสิทธิภาพ เนื่องจากอาจทำให้เกิดภาระประสิทธิภาพที่สำคัญ

\ iii) การป้องกันการสร้าง gadget: ตามที่แนะนำใน §5.2 TIKTAG-v2 gadget สามารถลดได้โดยการเพิ่มคำสั่งระหว่างคำสั่ง store และ load TIKTAGv1 gadget แม้ว่าเราจะยังไม่พบที่สามารถใช้ประโยชน์ได้ สามารถลดได้โดยการเพิ่มคำสั่งระหว่างสาขาและการเข้าถึงหน่วยความจำ ตามที่อธิบายใน §5.1

\ 6.2. การโจมตี Linux Kernel

Linux kernel บน ARM ถูกใช้อย่างแพร่หลายสำหรับอุปกรณ์มือถือ เซิร์ฟเวอร์ และอุปกรณ์ IoT ทำให้เป็นเป้าหมายการโจมตีที่น่าสนใจ การใช้ประโยชน์จากช่องโหว่การทำลายหน่วยความจำใน kernel สามารถยกระดับสิทธิ์ของผู้ใช้ และดังนั้น MTE จึงเป็นกลไกการป้องกันที่มีแนวโน้มสำหรับ Linux kernel การโจมตีที่อิงจาก TIKTAG ต่อ Linux kernel มีความท้าทายที่เป็นเอกลักษณ์ซึ่งแตกต่างจากการโจมตีเบราว์เซอร์ (§6.1)

\ นี่เป็นเพราะพื้นที่หน่วยความจำของผู้โจมตีถูกแยกออกจากพื้นที่หน่วยความจำของ kernel ที่ gadget จะถูกดำเนินการ ต่อไปนี้ เราจะสรุปภาพรวมของโมเดลภัยคุกคามของ Linux kernel (§6.2.1) และให้ TIKTAG gadget แบบ proof-of-concept ที่เราค้นพบใน Linux kernel (§6.2.2) สุดท้าย เราจะแสดงให้เห็นประสิทธิผลของ TIKTAG gadgets ในการใช้ประโยชน์จากช่องโหว่ของ Linux kernel (§6.2.3)

\ ==6.2.1. โมเดลภัยคุกคาม== โมเดลภัยคุกคามที่นี่เหมือนกับการโจมตียกระดับสิทธิ์ทั่วไปต่อ kernel เป็นส่วนใหญ่ โดยเฉพาะ เรามุ่งเน้นไปที่ Android Linux kernel ที่อิงจาก ARM ซึ่งเสริมความแข็งแกร่งด้วยการป้องกัน kernel เริ่มต้น (เช่น KASLR, SMEP, SMAP และ CFI) เราสมมติเพิ่มเติมว่า kernel ถูกเสริมความแข็งแกร่งด้วยโซลูชันการแท็กแบบสุ่ม MTE คล้ายกับโซลูชัน MTE ที่พร้อมใช้งานจริง Scudo [3]

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

\ แท็กที่ไม่ตรงกันจะยกข้อผิดพลาดการตรวจสอบแท็ก ซึ่งไม่พึงประสงค์สำหรับการใช้ประโยชน์ในโลกจริง ความท้าทายที่สำคัญประการหนึ่งในการโจมตีนี้คือ gadget ควรถูกสร้างขึ้นโดยการใช้โค้ด kernel ที่มีอยู่ซ้ำและดำเนินการโดย system calls ที่ผู้โจมตีสามารถเรียกใช้ได้ เนื่องจากสถาปัตยกรรม ARMv8 แยกตารางหน้าของผู้ใช้และ kernel, gadgets พื้นที่ผู้ใช้ไม่สามารถเข้าถึงหน่วยความจำ kernel แบบคาดเดา การตั้งค่านี้แตกต่างอย่างมากจากโมเดลภัยคุกคามของการโจมตีเบราว์เซอร์ (§6.1) ซึ่งใช้ประโยชน์จากโค้ดที่ผู้โจมตีจัดเตรียมเพื่อสร้าง gadget เราแยก gadget construction ที่อิงจาก eBPF ออก [17, 28] เพราะ eBPF ไม่พร้อมใช้งานสำหรับกระบวนการ Android ที่ไม่มีสิทธิ์ [33]

\ ==6.2.2. Kernel TikTag Gadget== ตามที่อธิบายใน §4.1 TIKTAG gadgets ควรตอบสนองข้อกำหนดหลายประการ และแต่ละข้อกำหนดมีความท้าทายในสภาพแวดล้อม kernel

ประการแรก ใน BR การคาดการณ์สาขาผิดพลาดควรถูกกระตุ้นด้วย cond_ptr ซึ่งควรควบคุมได้จากพื้นที่ผู้ใช้ เนื่องจากโปรเซสเซอร์ AArch64 ล่าสุดแยกการฝึกการคาดการณ์สาขาระหว่างผู้ใช้และ kernel [33] การฝึกสาขาจำเป็นต้องดำเนินการจากพื้นที่ kernel

ประการที่สอง ใน CHECK guess_ptr ควรถูกอ้างอิงถึง guess_ptr ควรถูกสร้างขึ้นจากพื้นที่ผู้ใช้เพื่อให้มีแท็กที่เดา (Tg) และชี้ไปที่ที่อยู่ kernel (เช่น target_addr) เพื่อรั่วไหลแท็ก (Tm) ซึ่งแตกต่างจากสภาพแวดล้อม JavaScript ของเบราว์เซอร์ (§6.1) ข้อมูลที่ผู้ใช้จัดเตรียมถูกฆ่าเชื้ออย่างหนักใน system calls ดังนั้นจึงยากที่จะสร้างพอยน์เตอร์ kernel แบบกำหนดเอง

\ ตัวอย่างเช่น access_ok() แน่ใจว่าพอยน์เตอร์ที่ผู้ใช้จัดเตรียมชี้ไปที่พื้นที่ผู้ใช้ และแมโคร array_index_nospec ป้องกันการเข้าถึงนอกขอบเขตแบบคาดเดาด้วยดัชนีที่ผู้ใช้จัดเตรียม ดังนั้น guess_ptr ควรเป็นพอยน์เตอร์ kernel ที่มีอยู่ โดยเฉพาะพอยน์เตอร์ที่มีช่องโหว่ซึ่งทำให้เกิดการทำลายหน่วยความจำ ตัวอย่างเช่น พอยน์เตอร์แบบห้อยใน use-after-free (UAF) หรือพอยน์เตอร์นอกขอบเขตใน buffer overflow สามารถใช้ได้ สุดท้าย ใน TEST test_ptr ควรถูกอ้างอิงถึง และ test_ptr ควรเข้าถึงได้จากพื้นที่ผู้ใช้ เพื่อให้การวัดสถานะแคชง่ายขึ้น test_ptr ควรเป็นพอยน์เตอร์พื้นที่ผู้ใช้ที่จัดเตรียมผ่านอาร์กิวเมนต์ system call

\ ==Gadgets ที่ค้นพบ== เราวิเคราะห์โค้ดต้นฉบับของ Linux kernel ด้วยตนเองเพื่อหา TIKTAG gadget ที่ตอบสนองข้อกำหนดที่กล่าวถึงข้างต้น ผลลัพธ์คือ เราพบ TIKTAG-v1 gadget ที่มีศักยภาพในการใช้ประโยชน์ได้หนึ่งตัวใน snd_timer_user_read() (รูปที่ 10) gadget นี้ตอบสนองข้อกำหนดของ TIKTAG-v1 (§5.1) ที่บรรทัดที่ 10 (เช่น BR) คำสั่ง switch กระตุ้นการคาดการณ์สาขาผิดพลาดด้วยค่าที่ผู้ใช้ควบคุมได้ tu->tread (เช่น cond_ptr) ที่บรรทัดที่ 14-17 (เช่น CHECK) tread (เช่น guess_ptr) ถูกอ้างอิงโดยคำสั่ง load สี่คำสั่ง tread ชี้ไปที่ออบเจ็กต์ struct snd_timer_tread64 ที่ผู้โจมตีสามารถจัดสรรและปลดปล่อยได้ตามอำเภอใจ

\ หากช่องโหว่ชั่วคราวเปลี่ยน tread เป็นพอยน์เตอร์แบบห้อย มันสามารถใช้เป็น guess_ptr ที่บรรทัดที่ 20 (เช่น TEST) พอยน์เตอร์พื้นที่ผู้ใช้ buffer (เช่น test_ptr) ถูกอ้างอิงใน copy_to_user เนื่องจาก gadget นี้ไม่สามารถเข้าถึงได้โดยตรงจากพื้นที่ผู้ใช้ เราได้ทำการปรับเปลี่ยนเล็กน้อยกับโค้ด kernel; เราลบการส่งคืนก่อนกำหนดสำหรับกรณี default ที่บรรทัดที่ 6 ซึ่งแน่ใจว่า buffer ถูกเข้าถึงเฉพาะในเส้นทางคาดเดาเพื่อสังเกตความแตกต่างของสถานะแคชเนื่องจากการดำเนินการแบบคาดเดา

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

\ โดยเฉพาะอย่างยิ่ง TIKTAG-v1 อาศัย speculation shrinkage บนเหตุการณ์เส้นทางที่ผิด ซึ่งอาจรวมถึงข้อผิดพลาดการแปลที่อยู่หรือข้อยกเว้นอื่นๆ ในเส้นทางการคาดการณ์สาขาผิดพลาด เนื่องจาก system calls เกี่ยวข้องกับการไหลควบคุมที่ซับซ้อน speculation shrinkage อาจไม่ถูกกระตุ้นตามที่คาดหวัง นอกจากนี้ gadgets หลายตัวอาจสามารถใช้ประโยชน์ได้เมื่อโค้ด kernel เปลี่ยนแปลง ตัวอย่างเช่น TIKTAG-v1 gadget ใน ip6mr_ioctl() ไม่แสดงพฤติกรรมการรั่วไหลแท็ก MTE เมื่อถูกเรียกจากเส้นทาง system call (เช่น ioctl) อย่างไรก็ตาม gadget มีการรั่วไหลแท็กเมื่อถูกย้ายไปยัง syscalls อื่นๆ (เช่น write) ที่มีการไหลควบคุมแบบง่าย

\ ==6.2.3. การโจมตีบายพาส MTE ของ Kernel== รูปที่ 9b แสดงการโจมตีบายพาส MTE บน Linux kernel โดยใช้ช่องโหว่ use-after-free เป็นตัวอย่าง เราสมมติว่าผู้โจมตีได้ระบุ TIKTAG gadget ที่สอดคล้องกัน SysTikTagUAF() ที่สามารถรั่วไหลผลการตรวจสอบแท็กของพอยน์เตอร์แบบห้อยที่สร้างโดยช่องโหว่ ตัวอย่างเช่น TIKTAG-v1 gadget ใน snd_timer_user_read() (รูปที่ 10) สามารถรั่วไหลผลการตรวจสอบแท็กของ tread ซึ่งสามารถกลายเป็นพอยน์เตอร์แบบห้อยโดยช่องโหว่ use-after-free หรือ double-free

\ การโจมตีดำเนินการดังนี้: ประการแรก ผู้โจมตีปลดปล่อยออบเจ็กต์ kernel (เช่น objvuln) และทิ้งพอยน์เตอร์ (เช่น vuln_ptr) ไว้เป็นพอยน์เตอร์แบบห้อย ( 1 ) ถัดไป ผู้โจมตีจัดสรรออบเจ็กต์ kernel อื่น (เช่น objtarget) ที่ที่อยู่ของ objvuln ด้วย SysAllocTarget() ( 2 ) จากนั้น ผู้โจมตีเรียก SysTikTag() ด้วย buffer พื้นที่ผู้ใช้ (เช่น ubuf) ( 3 ) และรั่วไหลผลการตรวจสอบแท็ก (เช่น Tm == Tg) โดยการวัดเลเทนซีการเข้าถึงของ ubuf ( 4 ) หากแท็กตรงกัน ผู้โจมตีจะกระตุ้น SysExploitUAF(), system call ที่ใช้ประโยชน์จากช่องโหว่ use-after-free ( 5 ) มิฉะนั้น ผู้โจมตีจะจัดสรร objtarget ใหม่จนกว่าแท็กจะตรงกัน

\ ==การกระตุ้น Cache Side-Channel== เช่นเดียวกับ §6.1.3 การใช้ประโยชน์จาก TIKTAG gadget ที่สำเร็จต้องการ i) branch training, ii) cache control และ iii) cache measurement สำหรับ branch training ผู้โจมตีสามารถฝึกตัวคาดการณ์สาขาและกระตุ้นการคาดเดาด้วยเงื่อนไขสาขาที่ผู้ใช้ควบคุมจากพื้นที่ผู้ใช้ สำหรับ cache control ผู้โจมตีสามารถล้าง buffer พื้นที่ผู้ใช้ (เช่น ubuf) ในขณะที่ที่อยู่หน่วยความจำ kernel สามารถไล่ออกโดยการเด้งแคชไลน์ [25] สำหรับ cache measurement เลเทนซีการเข้าถึงของ ubuf สามารถวัดได้ด้วยตัวนับเสมือน (เช่น CNTVCT_EL0) หรือตัวจับเวลาที่อิงจากตัวนับหน่วยความจำ (เช่น ความละเอียดใกล้วงจร CPU)

\ ==การใช้ประโยชน์จากช่องโหว่การทำลายหน่วยความจำ== TIKTAG gadgets ช่วยให้สามารถบายพาส MTE และใช้ประโยชน์จากช่องโหว่การทำลายหน่วยความจำของ kernel ผู้โจมตีสามารถเรียก TIKTAG gadget ใน kernel เพื่อกระตุ้นการทำลายหน่วยความจำแบบคาดเดาและรับผลการตรวจสอบแท็ก จากนั้น ผู้โจมตีสามารถรับผลการตรวจสอบแท็ก และกระตุ้นการทำลายหน่วยความจำเฉพาะเมื่อแท็กตรงกัน เราอธิบายรายละเอียดกระบวนการโจมตีบายพาส MTE ของ Linux kernel ใน §D

\ ==6.2.4. การป้องกัน== เพื่อลด TIKTAG gadget ใน Linux kernel นักพัฒนา kernel ควรพิจารณาการป้องกันต่อไปนี้:

i) Speculation barrier: Speculation barriers สามารถลด TIKTAG-v1 gadget ใน Linux kernel ได้อย่างมีประสิทธิภาพ เพื่อป้องกันผู้โจมตีจากการรั่วไหลผลการตรวจสอบแท็กผ่าน buffer พื้นที่ผู้ใช้ ฟังก์ชัน kernel ที่เข้าถึงที่อยู่พื้นที่ผู้ใช้ เช่น copy_to_user และ copy_from_user สามารถเสริมความแข็งแกร่งด้วย speculation barriers ตามที่อธิบายใน §5.1 การรั่วไหลผลการตรวจสอบแท็กด้วยการเข้าถึง store สามารถลดได้โดยการวาง speculation barrier ก่อนการเข้าถึง store (เช่น TEST)

\ ตัวอย่างเช่น เพื่อลด gadgets ที่ใช้ประโยชน์จาก copy_to_user, speculation barrier สามารถแทรกก่อนการเรียก copy_to_user สำหรับ gadgets ที่ใช้การเข้าถึง load ไปยัง buffer พื้นที่ผู้ใช้ barriers ลด gadgets หากแทรกระหว่างสาขาและการเข้าถึงหน่วยความจำ kernel (เช่น CHECK) ตัวอย่างเช่น เพื่อลด gadgets ที่ใช้ประโยชน์จาก copy_from_user นักพัฒนา kernel ควรวิเคราะห์โค้ดเบส kernel อย่างระมัดระวังเพื่อหารูปแบบของสาขาเงื่อนไข การเข้าถึงหน่วยความจำ kernel และ copy_from_user() และแทรก speculation barrier ระหว่างสาขาและการเข้าถึงหน่วยความจำ kernel

\ ii) การป้องกันการสร้าง gadget: เพื่อกำจัด TIKTAG gadgets ที่มีศักยภาพใน Linux kernel โค้ดต้นฉบับ kernel สามารถวิเคราะห์และแพตช์ได้ เนื่องจาก TIKTAG gadgets สามารถสร้างได้ด้วยการปรับแต่งคอมไพเลอร์ การวิเคราะห์ไบนารีสามารถดำเนินการได้ สำหรับแต่ละ gadget ที่ค้นพบ คำสั่งสามารถจัดเรียงใหม่หรือคำสั่งเพิ่มเติมสามารถแทรกเพื่อป้องกันการสร้าง gadget ตามกลยุทธ์การป้องกันใน §5.1 และ §5.2

:::info ผู้เขียน:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info เอกสารนี้ มีอยู่บน arxiv ภายใต้ใบอนุญาต CC 4.0

:::

\