ธีโอ เดอ ราดท์ วางแผนที่จะเสริมความแข็งแกร่งให้กับกลไกการป้องกันหน่วยความจำ W^X (Write XOR Execute) สาระสำคัญของกลไกนี้คือไม่สามารถเข้าถึงหน้าหน่วยความจำกระบวนการได้พร้อมกันสำหรับการเขียนและการดำเนินการ ดังนั้นโค้ดจึงสามารถดำเนินการได้หลังจากปิดใช้งานการเขียนแล้วเท่านั้น และการเขียนไปยังเพจหน่วยความจำจะทำได้หลังจากปิดใช้งานการดำเนินการแล้วเท่านั้น กลไก W^X ช่วยปกป้องแอปพลิเคชันพื้นที่ผู้ใช้จากการโจมตีบัฟเฟอร์ล้นทั่วไป รวมถึงสแต็กโอเวอร์โฟลว์ และทำงานอยู่ใน OpenBSD .
จากการเริ่มต้นทำงานกับ W^X เป็นที่ชัดเจนว่านี่เป็นเส้นทางที่ยาวนาน เนื่องจากมีแอปพลิเคชันจำนวนมากที่ใช้ JIT การใช้งาน JIT สามารถแบ่งออกได้เป็น XNUMX ประเภท:
- สลับหน่วยความจำระหว่างสถานะ W และ X โดยยอมรับ "ต้นทุน" ของการเรียกของระบบ .
- การสร้างนามแฝงระหว่างคู่ของการแมป W และ X ของหน่วยความจำเดียวกัน
- ตัวเลือกที่ “สกปรก” ที่สุดต้องใช้โมเดลหน่วยความจำ W|X ที่ช่วยให้สามารถบันทึกและดำเนินการได้พร้อมกัน
ในปัจจุบัน มีโปรแกรมที่ใช้ตัวเลือกที่สามน้อยลงอย่างเห็นได้ชัด และยังมีอีกมากที่ใช้ตัวเลือกที่หนึ่งและสอง อย่างไรก็ตาม เนื่องจากจำเป็นต้องรันโปรแกรมด้วย W|X JIT (ส่วนใหญ่เป็น Chromium และ Iridum) จึงเพิ่มตัวเลือกการเมานต์ระบบไฟล์ "wxallowed" ซึ่งช่วยให้สามารถใช้หน่วยความจำพร้อมกันสำหรับทั้งการเขียนและการดำเนินการ ในกรณีที่ ELF ที่ปฏิบัติการได้ ไฟล์ถูกทำเครื่องหมายด้วยเครื่องหมาย "wxneeded" และแอปพลิเคชันเองก็ได้รับการปกป้องเพิ่มเติมโดยใช้กลไก и เพื่อจำกัดรายการการเรียกระบบที่ใช้และส่วนของระบบไฟล์ที่พร้อมใช้งานสำหรับแอปพลิเคชันตามลำดับ
เพื่อให้การหาประโยชน์จากช่องโหว่ในแอปพลิเคชันดังกล่าวซับซ้อนยิ่งขึ้น จึงมีการเสนอกลไกเพิ่มเติม ซึ่งจะตรวจสอบว่าการเรียกของระบบกำลังดำเนินการจากเพจหน่วยความจำที่เขียนได้หรือไม่ หากเพจสามารถเขียนได้ กระบวนการจะถูกบังคับให้ยุติ ด้วยวิธีนี้ ผู้โจมตีจะไม่สามารถใช้ประโยชน์จากการเรียกของระบบได้ และจะถูกบังคับให้พยายามค้นหาอุปกรณ์ที่จำเป็นในการใช้งาน JIT หรือแม้แต่ทำงานที่ยากขึ้นในการตรวจจับ stubs การเรียกของระบบโดยตรงภายใน .
กระบวนการ Chrome/อิริเดียมได้รับการปกป้องอย่างน่าเชื่อถืออยู่แล้วโดยใช้คำมั่นสัญญาและเปิดเผย แต่การลบความสามารถในการใช้งานออก เช่น การเรียกระบบ write(2) มีข้อได้เปรียบอย่างเห็นได้ชัด เนื่องจากจะสร้างปัญหาเพิ่มเติมให้กับผู้โจมตี อย่างไรก็ตาม ปัญหาอาจเกิดขึ้นได้หากการใช้งาน JIT ใช้การเรียกระบบดั้งเดิมจากหน่วยความจำ W|X อย่างไรก็ตาม มีเหตุผลที่หวังว่าจะไม่เป็นเช่นนั้น เนื่องจาก ABI มีการเปลี่ยนแปลงหลายครั้ง แต่ยังไม่มีใครรายงานปัญหาเลย
การเปลี่ยนแปลงนี้มีอยู่แล้วในภาพรวมปกติของสาขา OpenBSD-Current ทุกคนที่สนใจได้รับเชิญให้ทดสอบ
ข่าวที่เกี่ยวข้องกับการปรากฏตัวของโหมดใน Chrome/Iridium สมควรได้รับความคิดเห็นแยกต่างหากจาก Theo . จากมุมมองของเขา สิ่งนี้เป็นที่ยอมรับสำหรับบางรุ่นการใช้งาน แต่อาจไม่ใช่ทั้งหมด เนื่องจากโหมดนี้จะเพิ่มภาระบนโปรเซสเซอร์อย่างเห็นได้ชัด ในปัจจุบัน Chrome ส่วนใหญ่จะใช้งานได้หากคุณปิดการใช้งาน "wxallowed" สำหรับ /usr/local แม้ว่าส่วนขยายบางรายการอาจมีปัญหาก็ตาม (ตัวอย่าง Ghostery) ไม่ทางใดก็ทางหนึ่ง Theo หวังว่าการทำงานที่เต็มเปี่ยมในโหมด JITless จะนำไปสู่สถานะการปฏิบัติงานเต็มรูปแบบในอนาคตอันใกล้นี้
ที่มา: opennet.ru