Checkpoint เสนอเทคนิคการป้องกัน Safe-Linking ทำให้ยากต่อการใช้ประโยชน์จากช่องโหว่

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

แพตช์ที่ใช้ Safe-Linking ได้รับการจัดเตรียมสำหรับ Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) และ Google TCMalloc และยังเสนอให้อัปเกรดการป้องกันใน Chromium (ใน
ตั้งแต่ปี 2012 Chromium ได้สร้างเทคนิคการป้องกัน MaskPtr ไว้แล้วโดยมีเป้าหมายเพื่อแก้ไขปัญหาเดียวกัน แต่โซลูชันจาก Checkpoint แสดงให้เห็นประสิทธิภาพที่สูงกว่า)
แพตช์ที่แนะนำได้รับการอนุมัติให้จัดส่งในรุ่นเดือนสิงหาคมแล้ว Glibc3.32 และการเชื่อมโยงอย่างปลอดภัยจะถูกเปิดใช้งานตามค่าเริ่มต้น uClibc-NG รองรับการเชื่อมโยงอย่างปลอดภัย ป้อน รวมอยู่ในรุ่น 1.0.33 และเปิดใช้งานตามค่าเริ่มต้น การเปลี่ยนแปลงใน gperftools (tcmalloc เก่า) ได้รับการยอมรับแต่จะเสนอเป็นตัวเลือกในการเปิดตัวครั้งต่อๆ ไป

นักพัฒนา ทีซีมอลลอค (tcmalloc ใหม่) ปฏิเสธที่จะยอมรับ เปลี่ยนแปลงโดยอ้างถึงประสิทธิภาพที่ลดลงอย่างรุนแรงและความจำเป็นในการเพิ่มการทดสอบที่ครอบคลุมเพื่อตรวจสอบเป็นประจำว่าทุกอย่างทำงานตามที่คาดหวัง การทดสอบโดยวิศวกรของ Checkpoint แสดงให้เห็นว่าวิธี Safe-Linking ไม่ได้นำไปสู่การใช้หน่วยความจำเพิ่มเติม และประสิทธิภาพเมื่อดำเนินการฮีปลดลงโดยเฉลี่ยเพียง 0.02% และในสถานการณ์กรณีที่เลวร้ายที่สุด 1.5% (สำหรับการเปรียบเทียบ ต้นทุนค่าโสหุ้ย ในวิธีที่ใช้ใน Chromium มีค่าประมาณ “น้อยกว่า 2%”) การรวม
การเชื่อมโยงอย่างปลอดภัยส่งผลให้มีการดำเนินการคำสั่งประกอบเพิ่มเติม 2-3 คำสั่งแต่ละครั้งที่เรียกใช้ free() และ 3-4 คำสั่งในแต่ละครั้งที่มีการเรียก malloc() ไม่จำเป็นต้องดำเนินการเริ่มต้นและขั้นตอนการสร้างค่าสุ่ม

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

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) ตำแหน่ง) >> 12) ^ ((size_t) ptr)))

+#กำหนด REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- ถัดไป = p->fd;
+ ถัดไป = REVEAL_PTR (p->fd);
...

สาระสำคัญของวิธีนี้คือการใช้ข้อมูลสุ่มจากกลไกการสุ่มที่อยู่ ASLR (mmap_base) เพื่อปกป้องรายการที่เชื่อมโยงเดี่ยวๆ เช่น Fast-Bins และ TCache ก่อนที่จะใช้ตัวชี้กับองค์ประกอบถัดไปในรายการกับค่า ตัวชี้จะทำการแปลงมาสก์และตรวจสอบการจัดแนวหน้า ตัวชี้จะถูกแทนที่ด้วยผลลัพธ์ของการดำเนินการ "(L >> PAGE_SHIFT) XOR (P)" โดยที่ P คือค่าของตัวชี้ และ L คือตำแหน่งหน่วยความจำที่จัดเก็บตัวชี้ไว้

เมื่อนำมาใช้ในระบบ ASLR (การสุ่มเค้าโครงพื้นที่ที่อยู่) ส่วนหนึ่งของบิต L ที่มีที่อยู่ฐานฮีปมีค่าสุ่มที่ใช้เป็นคีย์ในการเข้ารหัส P (แยกโดยการดำเนินการกะ 12 บิตสำหรับเพจขนาด 4096 ไบต์) การจัดการนี้จะช่วยลดความเสี่ยงของการไฮแจ็กพอยน์เตอร์ในการหาประโยชน์ เนื่องจากพอยน์เตอร์ไม่ได้ถูกจัดเก็บในรูปแบบดั้งเดิม และการแทนที่จะต้องอาศัยความรู้เกี่ยวกับการจัดสรรฮีป นอกจากนี้ รหัสแพทช์ยังมีการตรวจสอบเพิ่มเติมสำหรับการจัดตำแหน่งบล็อก ซึ่งไม่อนุญาตให้ผู้โจมตีแทนที่ตัวชี้ด้วยค่าที่ไม่ได้จัดตำแหน่ง และต้องทราบจำนวนบิตที่จัดตำแหน่ง ซึ่งในระบบ 64 บิตยังอนุญาตให้บล็อกเพิ่มเติม ความพยายามโจมตี 15 ครั้งจาก 16 ครั้งที่ไม่คำนึงถึงการวางแนว

วิธีการนี้มีประสิทธิภาพในการป้องกันการโจมตีที่ใช้การเขียนตัวชี้ใหม่บางส่วน (เปลี่ยนไบต์ต่ำ) เขียนตัวชี้ใหม่ทั้งหมด (เปลี่ยนเส้นทางไปยังรหัสของผู้โจมตี) และเปลี่ยนตำแหน่งรายการในที่อยู่ที่ไม่ได้จัดแนว ตามตัวอย่าง จะแสดงให้เห็นว่าการใช้ Safe-Linking ใน malloc จะทำให้สามารถบล็อกการหาประโยชน์ได้เมื่อเร็วๆ นี้ ระบุ โดยนักวิจัยช่องโหว่คนเดียวกัน CVE-2020-6007 ในไฟอัจฉริยะ Philips Hue Bridge ซึ่งเกิดจากการล้นของบัฟเฟอร์และช่วยให้คุณควบคุมอุปกรณ์ได้

ที่มา: opennet.ru