เหตุใดจึงยากที่จะทำให้ C มีแนวโน้มน้อยลงในการบัฟเฟอร์ล้น?

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

ฉันได้ทำการวิจัยเกี่ยวกับเรื่องนี้และการใช้ประโยชน์จากการใช้ประโยชน์เหล่านี้ยังมีอยู่ทุกหนทุกแห่งแม้กระทั่งตอนนี้ในสิ่งต่าง ๆ เช่นการใช้ homebrew บน Wiiและการเจลเบรคที่ไม่มีการผูกมัดสำหรับ iOS 4.3.1

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

แก้ไข: มุมมองอื่นที่ฉันต้องการคำตอบที่จะต้องพิจารณา - ทำไมผู้สร้างของ C ไม่สามารถแก้ไขปัญหาเหล่านี้ได้โดยการปรับใช้ห้องสมุดใหม่?

พวกเขาซ่อมห้องสมุด

ห้องสมุดมาตรฐานใด ๆ ที่ทันสมัย C มีสายพันธุ์ที่ปลอดภัยของstrcpy, strcat, sprintfและอื่น ๆ

บนระบบ C99 ซึ่งเป็น Unixes ส่วนใหญ่คุณจะพบสิ่งเหล่านี้ด้วยชื่อที่คล้ายกันstrncatและsnprintf"n" ซึ่งระบุว่าจะรับอาร์กิวเมนต์ที่ขนาดของบัฟเฟอร์หรือจำนวนองค์ประกอบสูงสุดที่จะคัดลอก

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

บน Windows, หนึ่งมักจะพบstrcat_s, sprintf_sที่ "_S" ต่อท้ายที่ระบุ "ปลอดภัย" สิ่งเหล่านี้ได้ค้นพบวิธีการของพวกเขาในไลบรารีมาตรฐาน C ใน C11 และให้การควบคุมเพิ่มเติมสิ่งที่เกิดขึ้นในกรณีที่มีการล้น (ยกตัวอย่างเช่นการตัดกับการยืนยัน)

ผู้ขายหลายรายมีทางเลือกที่ไม่ได้มาตรฐานมากกว่าเช่นasprintfใน GNU libc ซึ่งจะจัดสรรบัฟเฟอร์ขนาดที่เหมาะสมโดยอัตโนมัติ

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

มันไม่ถูกต้องจริงๆจะบอกว่าซีเป็นจริง "ข้อผิดพลาด" โดยการออกแบบ นอกเหนือจากความผิดพลาดที่น่าเศร้าเช่นgetsภาษา C ไม่สามารถเป็นอย่างอื่นได้โดยไม่สูญเสียคุณสมบัติหลักที่ดึงดูดผู้คนไปยัง C ในตอนแรก

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

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

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

เป็นการยากที่จะแก้ไขบัฟเฟอร์ล้นเนื่องจาก C ไม่มีเครื่องมือที่มีประโยชน์สำหรับแก้ไขปัญหา มันเป็นข้อบกพร่องภาษาพื้นฐานที่บัฟเฟอร์พื้นเมืองให้ไม่มีการป้องกันและมันเป็นจริงหากไม่สมบูรณ์ไม่สามารถที่จะแทนที่พวกเขาด้วยผลิตภัณฑ์ที่เหนือกว่าเช่น C ++ ทำกับstd::vectorและstd::array, และมันเป็นเรื่องยากแม้ภายใต้โหมดการแก้ปัญหาเพื่อหาบัฟเฟอร์ล้น

ปัญหาไม่ได้อยู่กับซีภาษา

IMO, อุปสรรคสำคัญเดียวที่จะเอาชนะก็คือ C เป็นเพียงธรรมดาสอนไม่ดี ทศวรรษของการปฏิบัติที่ไม่ดีและข้อมูลที่ผิดได้รับการจัดทำขึ้นในคู่มืออ้างอิงและบันทึกการบรรยายซึ่งทำให้จิตใจของนักเขียนโปรแกรมรุ่นใหม่แต่ละคนตั้งแต่ต้น นักเรียนจะได้รับคำอธิบายสั้น ๆ เกี่ยวกับฟังก์ชั่น I / O อย่างง่ายเช่นgets¹หรือscanfจากซ้ายไปยังอุปกรณ์ของตนเอง พวกเขาไม่ได้บอกว่าเครื่องมือเหล่านั้นสามารถล้มเหลวได้อย่างไรหรือวิธีป้องกันความล้มเหลวเหล่านั้น พวกเขาไม่ได้บอกเกี่ยวกับการใช้fgetsและstrtol/strtodเพราะสิ่งเหล่านี้ถือเป็นเครื่องมือ "ขั้นสูง" จากนั้นพวกเขาจะปลดปล่อยความเป็นมืออาชีพเพื่อสร้างความหายนะ ไม่ว่าโปรแกรมเมอร์ที่มีประสบการณ์จำนวนมากรู้ดีไปกว่านี้เพราะพวกเขาได้รับการศึกษาที่สมองเสียหาย มันน่าคลั่ง ฉันเห็นคำถามมากมายที่นี่และใน Stack Overflow และในเว็บไซต์อื่น ๆ ที่เห็นได้ชัดว่าบุคคลที่ถามคำถามนั้นถูกสอนโดยคนที่ไม่รู้ว่าพวกเขากำลังพูดถึงอะไรและแน่นอนคุณไม่สามารถพูดได้ "อาจารย์ของคุณผิด" เพราะเขาเป็นศาสตราจารย์และคุณก็แค่คนที่แต่งตัวประหลาดบนอินเทอร์เน็ต

และแล้วคุณมีฝูงชนที่ disdains คำตอบใด ๆ เริ่มต้นด้วย "ดีตามมาตรฐานภาษา ..." เพราะพวกเขากำลังทำงานอยู่ในโลกแห่งความจริงและเป็นไปตามมาตรฐานที่พวกเขาไม่ได้นำไปใช้กับโลกแห่งความจริง ฉันสามารถจัดการกับคนที่เพิ่งได้รับการศึกษาที่ไม่ดี แต่ใครก็ตามที่ยืนยันว่าเป็นคนโง่เขลานั้นเป็นเพียงความเสียหายต่ออุตสาหกรรม

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

ใช่นี่เป็นการคุยโว

ปัญหาคือหนึ่งในความสามารถในการบริหารจัดการสั้นกว่าความสามารถของโปรแกรมเมอร์ โปรดจำไว้ว่าแอปพลิเคชัน 90,000 บรรทัดต้องการการดำเนินการที่ไม่ปลอดภัยเพียงหนึ่งครั้งเท่านั้นที่จะไม่ปลอดภัยอย่างสมบูรณ์ เกือบจะเกินขอบเขตของความเป็นไปได้ที่แอปพลิเคชันใด ๆ ที่เขียนบนการจัดการสตริงที่ไม่ปลอดภัยขั้นพื้นฐานจะสมบูรณ์แบบ 100% - ซึ่งหมายความว่าจะไม่ปลอดภัย

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

หนึ่งในพลังที่ยิ่งใหญ่ของการใช้ C คือมันช่วยให้คุณสามารถจัดการกับหน่วยความจำในแบบที่คุณเห็นสมควร

หนึ่งในจุดอ่อนที่สำคัญของการใช้ C คือช่วยให้คุณสามารถจัดการกับหน่วยความจำในแบบที่คุณเห็นว่าเหมาะสม

มีฟังก์ชันที่ไม่ปลอดภัยใด ๆ ในรุ่นที่ปลอดภัย อย่างไรก็ตามโปรแกรมเมอร์และคอมไพเลอร์ไม่บังคับใช้อย่างเคร่งครัด

เหตุใดผู้สร้าง C ไม่สามารถแก้ไขปัญหาเหล่านี้ได้โดยการนำไลบรารีไปใช้อีกครั้ง

อาจเป็นเพราะ C ++ ทำสิ่งนี้แล้วและสามารถใช้งานร่วมกับรหัส C ย้อนหลังได้ ดังนั้นหากคุณต้องการประเภทสตริงที่ปลอดภัยในรหัส C ของคุณคุณเพียงแค่ใช้ std :: string และเขียนรหัส C ของคุณโดยใช้คอมไพเลอร์ C ++

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

ฉันคิดว่าปัญหาคือว่างานประจำ strcpy ฯลฯ ยังคงมีอยู่ หากพวกเขาถูกลบออกในความโปรดปรานของ strncpy ฯลฯ นั้นจะช่วย

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

บางส่วนของชุมชนการเขียนโปรแกรมไม่ต้องการเสียบรูเหล่านั้น เพียงแค่ดูเปลวไฟสงครามที่เริ่มต้นด้วยสายอาร์เรย์ตัวชี้การรวบรวมขยะ ...