จุดตรวจ (ผู้ให้บริการโซลูชั่นความปลอดภัยไอทีระดับโลก) เปิดตัวเมื่อหลายวันก่อนการแนะนำ ของกลไกความปลอดภัย "Safe-Linking" นี้ ทำให้ยากที่จะสร้างช่องโหว่ ที่ปรับเปลี่ยนคำจำกัดความหรือการเปลี่ยนแปลงของพอยน์เตอร์เป็นบัฟเฟอร์ที่จัดสรรเมื่อทำการเรียก malloc
กลไก« Safe-Linking »ใหม่ ไม่ได้ปิดกั้นความเป็นไปได้ในการใช้ประโยชน์จากช่องโหว่อย่างสมบูรณ์ แต่ โดยมีค่าใช้จ่ายน้อยที่สุด ทำให้การสร้างช่องโหว่บางประเภทซับซ้อนขึ้นนอกจากบัฟเฟอร์ล้นที่ใช้ประโยชน์แล้วจำเป็นต้องหาช่องโหว่อื่นที่ทำให้เกิดข้อมูลเกี่ยวกับตำแหน่งของฮีปในหน่วยความจำ
แพตช์การใช้งาน Safe-Linking ได้เตรียมไว้สำหรับ Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) และ Google TCMalloc ตลอดจนข้อเสนอเพื่อปรับปรุงการป้องกันใน Chromium ให้ทันสมัย (ตั้งแต่ปี 2012 Chromium ได้รวมเข้ากับโซลูชันของ ปัญหาเดียวกัน) เทคนิคการป้องกัน MaskPtr แต่โซลูชันของ Checkpoint แสดงประสิทธิภาพที่ดีกว่า)
แพตช์ที่นำเสนอได้รับการอนุมัติให้จัดส่งแล้วใน Glibc 3.32 รุ่นเดือนสิงหาคมและ Safe-Linking จะเปิดใช้งานตามค่าเริ่มต้น ใน uClibc-NG การรองรับลิงก์ที่ปลอดภัยรวมอยู่ในเวอร์ชัน 1.0.33 และเปิดใช้งานโดยค่าเริ่มต้น ใน gperftools (tcmalloc เก่า) การเปลี่ยนแปลงได้รับการยอมรับ แต่จะเสนอเป็นตัวเลือกในการเปิดตัวในอนาคต
นักพัฒนา TCMalloc ปฏิเสธที่จะยอมรับการเปลี่ยนแปลงคด้วยความสำเร็จด้านประสิทธิภาพที่แข็งแกร่งและจำเป็นต้องเพิ่มการทดสอบขั้นสูงเพื่อตรวจสอบอย่างสม่ำเสมอว่าทุกอย่างทำงานได้อย่างถูกต้อง
การทดสอบดำเนินการโดย วิศวกรประจำจุดตรวจพบว่าวิธี Safe-Linking ไม่ได้ทำให้ใช้หน่วยความจำเพิ่ม และประสิทธิภาพเมื่อดำเนินการฮีปโดยเฉลี่ยจะลดลงเพียง 0.02% และในกรณีที่เลวร้ายที่สุด 1.5%
การเปิดใช้งาน Safe-Linking จะนำไปสู่การดำเนินการตามคำสั่งของแอสเซมเบลอร์เพิ่มเติม 2-3 คำสั่งในแต่ละครั้งที่โทรไปยังฟรี () และ 3-4 คำสั่งเมื่อโทรไปที่ malloc () ไม่จำเป็นต้องมีการเริ่มต้นและการสร้างค่าสุ่ม
Safe-Linking สามารถใช้ได้ไม่เพียง แต่เพื่อเพิ่มความปลอดภัย ของการใช้งานฮีปต่างๆ sนอกจากนี้ยังเพิ่มการตรวจสอบความสมบูรณ์ให้กับโครงสร้างข้อมูลใด ๆ ที่ใช้รายการของพอยน์เตอร์ที่เชื่อมโยงทีละรายการซึ่งอยู่ถัดจากบัฟเฟอร์
วิธีการ มันง่ายมากในการใช้งานและต้องเพิ่มมาโครเท่านั้น และนำไปใช้กับพอยน์เตอร์ในบล็อกถัดไปของโค้ด (ตัวอย่างเช่นสำหรับ Glibc มีการเปลี่ยนแปลงโค้ดเพียงไม่กี่บรรทัด)
สาระสำคัญของวิธีนี้คือการใช้ข้อมูลแบบสุ่มจากกลไกการสุ่มที่อยู่ ASLR (mmap_base) เพื่อป้องกันรายการที่เชื่อมโยงทีละรายการเช่น Fast-Bins และ TCache ก่อนที่จะใช้ค่าตัวชี้กับรายการถัดไปในรายการการแปลงมาสก์และการตรวจสอบการจัดแนวจะดำเนินการตามขอบของหน้าหน่วยความจำ ตัวชี้จะถูกแทนที่ด้วยผลลัพธ์ของการดำเนินการ "(L >> PAGE_SHIFT) XOR (P)" โดยที่ P คือค่าของตัวชี้และ L คือตำแหน่งในหน่วยความจำที่จัดเก็บตัวชี้นี้
เมื่อใช้ในระบบ ASLR (Address Space Layout Randomization) บิต L บางตัวที่มีแอดเดรสฐานของฮีปจะมีค่าสุ่มที่ใช้เป็นคีย์ในการเข้ารหัส P (ถูกแยกโดยการดำเนินการ shift 12 บิต สำหรับหน้า 4096 ไบต์)
การจัดการดังกล่าว ลดความเสี่ยงในการจับตัวชี้เพื่อหาประโยชน์ เนื่องจากตัวชี้ไม่ได้ถูกจัดเก็บในรูปแบบดั้งเดิมและในการแทนที่คุณจำเป็นต้องทราบข้อมูลเกี่ยวกับตำแหน่งของฮีป
วิธีนี้มีประสิทธิภาพในการป้องกันการโจมตีที่ใช้การกำหนดค่าตัวชี้ใหม่บางส่วน (กะไบต์ต่ำ), การเขียนพอยน์เตอร์ใหม่ทั้งหมด (เปลี่ยนเส้นทางไปยังรหัสของผู้โจมตี) และเปลี่ยนตำแหน่งของรายการในทิศทางที่ไม่อยู่ในแนวเดียวกัน
ตัวอย่างเช่นแสดงให้เห็นว่าการใช้ Safe-Linking ใน malloc จะบล็อกการใช้ประโยชน์จากช่องโหว่ CVE-2020-6007 ที่เพิ่งค้นพบโดยนักวิจัยคนเดียวกันในไฟแบ็คไลท์อัจฉริยะของ Philips Hue Bridge ที่เกิดจากการล้นของบัฟเฟอร์และอนุญาตให้ควบคุมได้ อุปกรณ์
Fuente: https://research.checkpoint.com