ป้องกันบัฟเฟอร์ล้น

การป้องกันบัฟเฟอร์ล้นคือเทคนิคต่างๆ ที่ใช้ระหว่างการพัฒนาซอฟต์แวร์เพื่อเพิ่มความปลอดภัยของโปรแกรมปฏิบัติการโดยการตรวจจับบัฟเฟอร์โอเวอร์โฟลว์บน ตัวแปรที่จัดสรร สแต็กและป้องกันไม่ให้ทำให้เกิดพฤติกรรมที่ไม่เหมาะสมของโปรแกรมหรือกลายเป็นช่องโหว่ด้านความปลอดภัย ที่ร้ายแรง บัฟเฟอร์ล้นของสแต็กเกิดขึ้นเมื่อโปรแกรมเขียนไปยังที่อยู่หน่วยความจำบนสแต็กการเรียกของโปรแกรมภายนอกโครงสร้างข้อมูลที่ต้องการ ซึ่งโดยปกติจะเป็นบัฟเฟอร์ที่มีความยาวคงที่ ข้อบกพร่องบัฟเฟอร์ล้นของสแต็กเกิดขึ้นเมื่อโปรแกรมเขียนข้อมูลไปยังบัฟเฟอร์ที่อยู่บนสแต็กมากกว่าที่จัดสรรไว้จริงสำหรับบัฟเฟอร์นั้น ซึ่งมักจะส่งผลให้เกิดความเสียหายกับข้อมูลที่อยู่ติดกันบนสแต็ก ซึ่งอาจส่งผลให้โปรแกรมหยุดทำงาน การทำงานไม่ถูกต้อง หรือปัญหาด้านความปลอดภัย

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

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

มีการใช้งานการป้องกันบัฟเฟอร์ล้นหลายแบบ รวมถึงการใช้งานสำหรับGNU Compiler Collection , LLVM , Microsoft Visual Studioและคอมไพเลอร์อื่นๆ

ภาพรวม

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

บัฟเฟอร์ล้นของสแต็กอาจเกิดขึ้นโดยเจตนาโดยเป็นส่วนหนึ่งของการโจมตีที่เรียกว่าstack smashing หากโปรแกรมที่ได้รับผลกระทบทำงานด้วยสิทธิ์พิเศษ หรือหากยอมรับข้อมูลจากโฮสต์เครือข่ายที่ไม่น่าเชื่อถือ (เช่นเว็บเซิร์ฟเวอร์ สาธารณะ ) แสดงว่าจุดบกพร่องคือช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้น ซึ่งทำให้ผู้โจมตี สามารถ แทรกโค้ดปฏิบัติการลงในโปรแกรมที่รันอยู่และนำ การควบคุมกระบวนการ นี่เป็นหนึ่งในวิธีการที่เก่าแก่ที่สุดและเชื่อถือได้มากขึ้นสำหรับผู้โจมตีในการเข้าถึงคอมพิวเตอร์โดยไม่ได้รับอนุญาต[2]

โดยทั่วไปแล้ว การป้องกันบัฟเฟอร์ล้นจะปรับเปลี่ยนการจัดระเบียบข้อมูลในเฟรมสแต็กของการเรียกใช้ฟังก์ชันเพื่อรวมค่า "canary" ซึ่งเมื่อถูกทำลายแล้วจะแสดงว่าบัฟเฟอร์ที่อยู่ก่อนหน้านั้นในหน่วยความจำมีล้น สิ่งนี้ให้ประโยชน์ในการป้องกันการโจมตีทั้งระดับ ตามที่นักวิจัยบางคน[3]ผลกระทบของเทคนิคเหล่านี้มีน้อยมาก

การป้องกัน Stack-Smashing ไม่สามารถป้องกันการโจมตีบางรูปแบบได้ ตัวอย่างเช่น ไม่สามารถป้องกันบัฟเฟอร์ล้นในฮีปได้ ไม่มีวิธีที่สมเหตุสมผลในการปรับเปลี่ยนโครงร่างของข้อมูลภายในโครงสร้างโครงสร้างคาดว่าจะเหมือนกันระหว่างโมดูล โดยเฉพาะอย่างยิ่งกับไลบรารีแบบแบ่งใช้ ข้อมูลใดๆ ในโครงสร้างหลังจากบัฟเฟอร์ไม่สามารถป้องกันด้วยนกคีรีบูนได้ ดังนั้นโปรแกรมเมอร์จึงต้องระมัดระวังอย่างมากเกี่ยวกับวิธีการจัดระเบียบตัวแปรและใช้โครงสร้างของพวกเขา

นกคีรีบูน

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

คำศัพท์นี้เป็นการอ้างอิงถึงแนวทางปฏิบัติทางประวัติศาสตร์ในการใช้นกคีรีบูนในเหมืองถ่านหินเนื่องจากนกคีรีบูนจะได้รับผลกระทบจากก๊าซพิษเร็วกว่าคนงานเหมือง ดังนั้นจึงเป็นระบบเตือนภัยทางชีวภาพ นกคีรีบูนมีอีกชื่อหนึ่งว่าคุกกี้สแต็กซึ่งมีจุดมุ่งหมายเพื่อทำให้นึกถึงรูปภาพ "คุกกี้ที่เสียหาย" เมื่อค่าเสียหาย

นกคีรีบูนที่ใช้งาน อยู่มีสามประเภท: terminator , RandomและXORแบบสุ่ม StackGuard เวอร์ชันปัจจุบันรองรับทั้งสามส่วน ในขณะที่ ProPolice รองรับเทอร์มิเนเตอร์และนกคีรีบูน แบบสุ่ม

นกคีรีบูนเทอร์มิเนเตอร์

นกคีรีบูนเทอร์มิเนเตอร์ใช้ข้อสังเกตว่าการโจมตีบัฟเฟอร์ล้นส่วนใหญ่ขึ้นอยู่กับการดำเนินการสตริงบางอย่างซึ่งสิ้นสุดที่เทอร์มิเนเตอร์สตริง ปฏิกิริยาต่อการสังเกตนี้คือ นกคีรีบูนถูกสร้างขึ้นจาก จุดสิ้นสุดที่ เป็นโมฆะ , CR , LF และFFด้วยเหตุนี้ ผู้โจมตีจะต้องเขียนอักขระว่างก่อนที่จะเขียนที่อยู่ผู้ส่ง เพื่อหลีกเลี่ยงการเปลี่ยนแปลงนกขมิ้น วิธีนี้จะป้องกันการโจมตีstrcpy()และวิธีการอื่นๆ ที่กลับมาเมื่อคัดลอกอักขระว่าง ในขณะที่ผลลัพธ์ที่ไม่พึงประสงค์ก็คือรู้จักนกคีรีบูน แม้ว่าจะมีการป้องกัน ผู้โจมตีก็อาจเขียนทับ canary ด้วยค่าที่ทราบและข้อมูลการควบคุมด้วยค่าที่ไม่ตรงกัน ดังนั้น จึงส่งรหัสตรวจสอบ canary ซึ่งจะดำเนินการในไม่ช้าก่อนคำสั่งส่งคืนจากการโทรของโปรเซสเซอร์เฉพาะ

นกคีรีบูนแบบสุ่ม

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

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

สุ่มนกคีรีบูน XOR

นกคีรีบูน XOR แบบสุ่มเป็นนกคีรีบูนแบบสุ่มที่ถูกสัญญาณรบกวน XOR โดยใช้ข้อมูลควบคุมทั้งหมดหรือบางส่วน ด้วยวิธีนี้ เมื่อนกขมิ้นหรือข้อมูลควบคุมถูกบดบัง ค่านกขมิ้นก็จะผิด

นกคีรีบูนแบบสุ่ม XOR มีช่องโหว่เช่นเดียวกับนกคีรีบูนแบบสุ่ม ยกเว้นว่าวิธีการ "อ่านจากสแต็ก" ในการรับนกคีรีบูนนั้นซับซ้อนกว่าเล็กน้อย ผู้โจมตีจะต้องได้รับ Canary, อัลกอริธึม และข้อมูลการควบคุม เพื่อสร้าง Canary ดั้งเดิมขึ้นมาใหม่ ซึ่งจำเป็นสำหรับการปลอมแปลงการป้องกัน

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

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

การตรวจสอบขอบเขต

การตรวจสอบขอบเขตเป็นเทคนิคที่ใช้คอมไพเลอร์ซึ่งจะเพิ่มข้อมูลขอบเขตรันไทม์สำหรับแต่ละบล็อกหน่วยความจำที่จัดสรร และตรวจสอบพอยน์เตอร์ทั้งหมดกับข้อมูล ณ รันไทม์ สำหรับ C และ C++ การตรวจสอบขอบเขตสามารถทำได้ในเวลาการคำนวณตัวชี้[4]หรือในเวลาอ้างอิง[5] [6] [7]

การดำเนินการตามแนวทางนี้ใช้พื้นที่เก็บข้อมูลส่วนกลาง ซึ่งอธิบายแต่ละบล็อกหน่วยความจำที่จัดสรร[4] [5] [6]หรือพอยน์เตอร์พอยน์เตอร์ [ 7]ซึ่งมีทั้งพอยน์เตอร์และข้อมูลเพิ่มเติม อธิบายภูมิภาคที่พวกมันชี้ไป .

การแท็ก

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

ในอดีต การติดแท็กถูกนำมาใช้เพื่อการนำภาษาโปรแกรมระดับสูงไปใช้[9]ด้วยการสนับสนุนที่เหมาะสมจากระบบปฏิบัติการการแท็กยังสามารถใช้เพื่อตรวจจับบัฟเฟอร์ล้น[10] ตัวอย่างคือ คุณลักษณะฮาร์ดแวร์ บิต NXซึ่งรองรับโดยโปรเซสเซอร์ Intel , AMDและARM

การดำเนินการ

คอลเลกชันคอมไพเลอร์ GNU (GCC)

การป้องกัน Stack-Smashing ถูกนำมาใช้ครั้งแรกโดยStackGuardในปี 1997 และเผยแพร่ที่USENIX Security Symposiumปี 1998 [11] StackGuard เปิดตัวเป็นชุดแพตช์สำหรับแบ็กเอนด์ Intel x86 ของGCC 2.7 StackGuard ได้รับการบำรุงรักษาสำหรับ การแจกจ่าย Immunix Linux ตั้งแต่ปี 1998 ถึง 2003 และได้รับการขยายพร้อมกับการใช้งานสำหรับเทอร์มิเนเตอร์ นกคีรีบูน XOR แบบสุ่มและแบบสุ่ม StackGuard ได้รับการเสนอแนะให้รวมไว้ใน GCC 3.x ในการประชุมสุดยอด GCC 2003 [12]แต่ก็ไม่ประสบผลสำเร็จเลย

ตั้งแต่ปี 2544 ถึง 2548 IBMได้พัฒนาแพตช์ GCC สำหรับการป้องกัน Stack-Smashing หรือที่เรียกว่าProPoliceมีการปรับปรุงแนวคิดของ StackGuard โดยการวางบัฟเฟอร์ไว้หลังพอยน์เตอร์ในเครื่องและอาร์กิวเมนต์ของฟังก์ชันในเฟรมสแต็สิ่งนี้ช่วยหลีกเลี่ยงความเสียหายของพอยน์เตอร์ ป้องกันการเข้าถึงตำแหน่งหน่วยความจำโดยพลการ

วิศวกร ของ Red Hatระบุปัญหากับ ProPolice และในปี 2548 ได้นำการป้องกัน stack-smashing มาใช้ใหม่เพื่อรวมไว้ใน GCC 4.1 [14] [15]งานนี้แนะนำ-fstack-protectorแฟล็กซึ่งปกป้องเฉพาะฟังก์ชันที่มีช่องโหว่บางส่วนเท่านั้น และแฟ-fstack-protector-allล็กซึ่งปกป้องฟังก์ชันทั้งหมดไม่ว่าพวกเขาต้องการหรือไม่ก็ตาม[16]

ในปี 2012 วิศวกรของ Google-fstack-protector-strong ได้ติดตั้ง แฟล็กนี้เพื่อสร้างสมดุลที่ดีขึ้นระหว่างความปลอดภัยและประสิทธิภาพ[17]แฟล็กนี้จะปกป้องฟังก์ชันที่มีช่องโหว่มากกว่า-fstack-protectorฟังก์ชัน แต่ไม่ใช่ทุกฟังก์ชัน ซึ่งให้ประสิทธิภาพที่ดีกว่า-fstack-protector-all. มีให้บริการใน GCC ตั้งแต่เวอร์ชัน 4.9 [18]

แพ็คเกจFedoraทั้งหมด ได้รับการคอมไพล์ -fstack-protectorตั้งแต่ Fedora Core 5 และ-fstack-protector-strongตั้งแต่ Fedora 20 [19] [20]แพ็คเกจส่วนใหญ่ในUbuntuได้รับการคอมไพ-fstack-protectorล์ตั้งแต่ 6.10 [21]ทุก แพ็คเกจ Arch Linuxได้รับการคอมไพล์-fstack-protectorตั้งแต่ปี 2554 [22]แพ็คเกจ Arch Linux ทั้งหมดที่สร้างขึ้นตั้งแต่วันที่ 4 พฤษภาคม 2557 ใช้-fstack-protector-strong. [23]การป้องกันสแต็กใช้สำหรับบางแพ็คเกจในDebianเท่านั้น[24]และสำหรับระบบฐานFreeBSD ตั้งแต่ 8.0 เท่านั้น [25]การป้องกันสแต็กเป็นมาตรฐานในระบบปฏิบัติการบางระบบ รวมถึงOpenBSD , [26] Hardened Gentoo [27]และDragonFly BSD [ จำเป็นต้องอ้างอิง ]

StackGuard และ ProPolice ไม่สามารถป้องกันการโอเวอร์โฟลว์ในโครงสร้างที่จัดสรรโดยอัตโนมัติซึ่งล้นไปยังพอยน์เตอร์ของฟังก์ชัน อย่างน้อย ProPolice จะจัดเรียงลำดับการจัดสรรใหม่เพื่อให้ได้รับการจัดสรรโครงสร้างดังกล่าวก่อนพอยน์เตอร์ฟังก์ชัน มีการเสนอ กลไกแยกต่างหากสำหรับการป้องกันพอยน์เตอร์ใน PointGuard [28]และพร้อมใช้งานบน Microsoft Windows [29]

ไมโครซอฟต์ วิชวล สตูดิโอ

ชุดคอมไพเลอร์จาก Microsoft ใช้การป้องกันบัฟเฟอร์ล้นตั้งแต่เวอร์ชัน 2003 ผ่านทาง สวิตช์บรรทัดคำสั่ง /GSซึ่งเปิดใช้งานตามค่าเริ่มต้นตั้งแต่เวอร์ชัน 2005 [30]การใช้/GS-ปิดใช้งานการป้องกัน

ไอบีเอ็มคอมไพเลอร์

การป้องกัน Stack-Smashing สามารถเปิดใช้งานได้โดยแฟล็กคอมไพเลอ-qstackprotectร์[31]

เสียงดังกราว/ LLVM

Clang รองรับ-fstack-protectorตัวเลือกเดียวกันกับ GCC [32]และระบบ "safe stack" ( -fsanitize=safe-stack ) ที่แข็งแกร่งกว่าซึ่งมีผลกระทบต่อประสิทธิภาพต่ำในทำนองเดียวกัน[33] Clang ยังมีเครื่องตรวจจับบัฟเฟอร์ล้นสามตัว ได้แก่AddressSanitizer ( ), [6] UBSan ( ), [34] และ SafeCode ที่ไม่เป็นทางการ (อัปเดตล่าสุดสำหรับ LLVM 3.0) [35]-fsanitize=address-fsanitize=bounds

ระบบเหล่านี้มีข้อดีข้อเสียที่แตกต่างกันในแง่ของการลดประสิทธิภาพ โอเวอร์เฮดของหน่วยความจำ และคลาสของข้อบกพร่องที่ตรวจพบ การป้องกันสแต็กเป็นมาตรฐานในระบบปฏิบัติการบางระบบ รวมถึงOpenBSD [36]

อินเทลคอมไพเลอร์

คอมไพเลอร์ C และ C++ ของ Intel รองรับการป้องกันแบบ stack-smashing ด้วยตัวเลือกที่คล้ายกับตัวเลือกที่มีให้โดย GCC และ Microsoft Visual Studio [37]

ไม่ปลอดภัย C

Fail-Safe C [7]เป็นคอมไพเลอร์ ANSI C ที่ปลอดภัยสำหรับหน่วยความจำแบบโอเพ่นซอร์ส ซึ่งทำการตรวจสอบขอบเขตตามตัวชี้ไขมันและการเข้าถึงหน่วยความจำเชิงวัตถุ[38]

StackGhost (ใช้ฮาร์ดแวร์)

StackGhost คิดค้นโดย Mike Frantzen เป็นการปรับแต่งง่ายๆ ในรูทีนการหก/เติมหน้าต่างการลงทะเบียน ซึ่งทำให้บัฟเฟอร์ล้นยากต่อการใช้ประโยชน์มากขึ้น ใช้คุณสมบัติฮาร์ดแวร์ที่เป็นเอกลักษณ์ของ สถาปัตยกรรม Sun Microsystems SPARC (นั่นคือ: การหก/เติมหน้าต่างการลงทะเบียนในเฟรมที่เลื่อนออกไป) เพื่อตรวจจับการแก้ไขตัวชี้ กลับ (วิธีทั่วไปสำหรับการหาประโยชน์เพื่อแย่งชิงเส้นทางการดำเนินการ) อย่างโปร่งใสโดยอัตโนมัติ ปกป้องแอปพลิเคชันทั้งหมดโดยไม่ต้องมีการแก้ไขไบนารีหรือซอร์ส ผลกระทบด้านประสิทธิภาพไม่มีนัยสำคัญ น้อยกว่าหนึ่งเปอร์เซ็นต์ ปัญหา gdbที่เกิดขึ้นได้รับการแก้ไขโดย Mark Kettenis ในอีกสองปีต่อมา ทำให้สามารถเปิดใช้งานคุณสมบัตินี้ได้ หลังจากเหตุการณ์นี้ รหัส StackGhost ได้ถูกรวม (และปรับให้เหมาะสม) เข้ากับOpenBSD /SPARC

ดูสิ่งนี้ด้วย

อ้างอิง

  1. ฟิเธน, วิลเลียม แอล.; ซีคอร์ด, โรเบิร์ต (27-03-2550) "VT-MB การละเมิดขอบเขตหน่วยความจำ" ใบรับรองของสหรัฐอเมริกา
  2. เลวี, เอเลียส (1996-11-08) "ทุบกองเพื่อความสนุกสนานและผลกำไร" แพรก . 7 (49): 14.
  3. "บัฟเฟอร์ล้น: การโจมตีและการป้องกันช่องโหว่แห่งทศวรรษ*" (PDF ) เก็บถาวรจากต้นฉบับ(PDF)เมื่อ 2013-03-09
  4. ↑ ab "การตรวจสอบขอบเขตของ C" ด็อก.ic.ac.uk เก็บถาวรจากต้นฉบับเมื่อ 2016-03-26 . สืบค้นเมื่อ 27-04-2014 .
  5. ↑ ab "SAFECode: สถาปัตยกรรมเสมือนที่ปลอดภัย" Sva.cs.illinois.edu. 12-08-2552 ​สืบค้นเมื่อ 27-04-2014 .
  6. ↑ abc "google/sanitizers" 19 มิถุนายน 2564.
  7. ↑ abc "Fail-Safe C: หน้าแรก" Staff.aist.go.jp 2013-05-07. เก็บถาวรจากต้นฉบับเมื่อ 2016-07-07 . สืบค้นเมื่อ 27-04-2014 .
  8. "วันอังคารที่ 5 เมษายน พ.ศ.2548" (PDF ) Feustel.us . เก็บถาวรจากต้นฉบับ(PDF)เมื่อวันที่ 23 มิถุนายน2016 สืบค้นเมื่อ 2016-09-17 .
  9. สตีนคิสต์, ปีเตอร์; เฮนเนสซี, จอห์น (1987) "การตรวจสอบแท็กและประเภทใน LISP: วิธีฮาร์ดแวร์และซอฟต์แวร์" การตรวจสอบระบบปฏิบัติการ ACM Sigops 21 (4) พลอากาศเอก: 50–59 ดอย : 10.1145/36204.36183 .
  10. "ภาพรวมความปลอดภัย MCP เซิร์ฟเวอร์องค์กร ClearPath" (PDF ) Public.support.unisys.com เก็บถาวรจากต้นฉบับ(PDF)เมื่อ24-01-2013 สืบค้นเมื่อ 27-04-2014 .
  11. "เอกสาร - การประชุมสัมมนาด้านความปลอดภัย USENIX ครั้งที่ 7, พ.ศ. 2541" Usenix.org 12-04-2545 . สืบค้นเมื่อ 27-04-2014 .
  12. "การดำเนินการของการประชุมสุดยอดนักพัฒนา GCC" (PDF ) พฤษภาคม 2546. เก็บถาวรจากต้นฉบับเมื่อ 2004-07-15 . สืบค้นเมื่อ 2016-09-17 .{{cite web}}: CS1 maint: bot: ไม่ทราบสถานะ URL ดั้งเดิม ( ลิงก์ )
  13. "ส่วนขยาย GCC สำหรับการปกป้องแอปพลิเคชันจากการโจมตีแบบ Stack-Smashing" รีเสิร์ช. ibm.com สืบค้นเมื่อ 27-04-2014 .
  14. "ซีรีส์การเปิดตัว GCC 4.1 - การเปลี่ยนแปลง คุณสมบัติใหม่ และการแก้ไข - โครงการ GNU - มูลนิธิซอฟต์แวร์เสรี (FSF)" Gcc.gnu.org . สืบค้นเมื่อ 27-04-2014 .
  15. ^ "Richard Henderson - [rfc] การปรับใช้ตัวป้องกัน ibm stack-smashing ใหม่" Gcc.gnu.org . สืบค้นเมื่อ 27-04-2014 .
  16. "ตัวเลือกการปรับให้เหมาะสม - การใช้ GNU Compiler Collection (GCC)" Gcc.gnu.org . สืบค้นเมื่อ 27-04-2014 .
  17. ^ "Han Shen(ææ) - [PATCH] เพิ่มตัวเลือกใหม่ "-fstack-protector-strong" (patch / doc inside)" Gcc.gnu.org 14-06-2555 . สืบค้นเมื่อ 27-04-2014 .
  18. เอดจ์, เจค (5 กุมภาพันธ์ 2557) "การป้องกันสแต็กที่แข็งแกร่งสำหรับ GCC" ข่าวลินุกซ์รายสัปดาห์ สืบค้นเมื่อ 28 พฤศจิกายน 2557 . ได้เข้าสู่ GCC 4.9 แล้ว
  19. ^ "คุณลักษณะด้านความปลอดภัย" โครงการ Fedora 11-12-2556 . สืบค้นเมื่อ 27-04-2014 .
  20. "#1128 (เปลี่ยนจาก "-fstack-protector" เป็น "-fstack-protector-strong" ใน Fedora 20) – FESCo" Fedorahosted.org ​สืบค้นเมื่อ 27-04-2014 .
  21. ^ "ความปลอดภัย/คุณสมบัติ - Ubuntu Wiki" วิกิ. ubuntu.com สืบค้นเมื่อ 27-04-2014 .
  22. "FS#18864 : พิจารณาเปิดใช้งานการป้องกันการแตกกองซ้อนของ GCC (ProPolice, SSP) สำหรับแพ็คเกจทั้งหมด" Bugs.archlinux.org ​สืบค้นเมื่อ 27-04-2014 .
  23. "svntogit/packages.git - Git clone ของที่เก็บ 'แพ็คเกจ'"[ ลิงก์เสียถาวร ]
  24. ^ "สถิติการรักษาความปลอดภัย Debian" Outflux.net เก็บถาวรจากต้นฉบับเมื่อ 2014-04-28 . สืบค้นเมื่อ 27-04-2014 .
  25. "บันทึกประจำรุ่น FreeBSD 8.0-RELEASE" ฟรีบีเอสดี.org 13-11-2556 . สืบค้นเมื่อ 27-04-2014 .
  26. "หน้าคู่มือ gcc-local(1) ของ OpenBSD" gcc มาพร้อมกับ ส่วนขยายการป้องกันสแต็ก ProPoliceซึ่งเปิดใช้งานตามค่าเริ่มต้น
  27. "แข็งตัว/Toolchain - Gentoo Wiki" 31-07-2559. GCC ที่เสริมความแข็งแกร่งของ Gentoo จะเปิดสวิตช์ตัวป้องกันสแต็กตามค่าเริ่มต้น เว้นแต่จะมีการร้องขออย่างชัดเจนว่าไม่ทำเช่นนั้น
  28. "การประชุมสัมมนาด้านความปลอดภัย USENIX ครั้งที่ 12 — เอกสารทางเทคนิค"
  29. "บล็อก MSDN – รับข้อมูล ข้อมูลเชิงลึก ประกาศ และข่าวสารล่าสุดจากผู้เชี่ยวชาญและนักพัฒนาของ Microsoft ในบล็อก MSDN" 6 สิงหาคม 2564.
  30. ^ "/GS (การตรวจสอบความปลอดภัยของบัฟเฟอร์) (C++)" msdn.microsoft.com ​สืบค้นเมื่อ 27-04-2014 .
  31. "qstackprotect". Publib.boulder.ibm.com ​สืบค้นเมื่อ 27-04-2014 .
  32. ^ "รายชื่อผู้รับจดหมายเสียงดังกราว" Clang.llvm.org 28 เมษายน 2560 . สืบค้นเมื่อ 2022-11-16 .
  33. "SafeStack — เอกสาร Clang 17.0.0git" clang.llvm.org
  34. "คู่มือการใช้งาน Clang Compiler - เอกสาร Clang 3.5" เสียงดังกราว . llvm.org สืบค้นเมื่อ 27-04-2014 .
  35. "รหัสเซฟ". Safecode.cs.illinois.edu . สืบค้นเมื่อ 27-04-2014 .
  36. ^ "หน้าคู่มือ clang-local (1) ของ OpenBSD" เสียงดังกราวมาพร้อมกับการป้องกันสแต็กที่เปิดใช้งานตามค่าเริ่มต้น เทียบเท่ากับ ตัวเลือก -fstack-protector-strongในระบบอื่น
  37. "คู่มือผู้ใช้และการอ้างอิงสำหรับ Intel C++ Compiler 15.0: fstack-security-check, GS" ซอฟต์แวร์. intel.com ดึงข้อมูลเมื่อ2015-02-13 .
  38. "thesis.dvi" (PDF ) Staff.aist.go.jp . สืบค้นเมื่อ 2016-09-17 .

ลิงค์ภายนอก

  • การดำเนินการประชุมสุดยอด GCC 2003 (PDF)
  • ทำลายกองเพื่อความสนุกสนานและผลกำไร โดยAleph One
  • บ้านอย่างเป็นทางการของ ProPolice
  • หน้าแรกของ Immunix StackGuard
  • กระดาษ StackGuard ต้นฉบับใน USENIX Security 1998
  • StackGhost: การป้องกันสแต็กที่อำนวยความสะดวกด้วยฮาร์ดแวร์
  • การใช้งานโพรโพลิส FreeBSD 5.4 และ 6.2
  • สี่เทคนิคที่แตกต่างกันเพื่อหลีกเลี่ยงการป้องกัน StackShield และ StackGuard
  • ตัวป้องกัน Stack Smashing
ดึงมาจาก "https://en.wikipedia.org/w/index.php?title=Buffer_overflow_protection&oldid=1215853144"