Java มีบัฟเฟอร์ล้นหรือไม่

Java มีบัฟเฟอร์ล้นหรือไม่ ถ้าใช่คุณช่วยอธิบายสถานการณ์ให้ฉันฟังได้ไหม

เนื่องจาก Java Strings ขึ้นอยู่กับอาร์เรย์ char และ Java จะตรวจสอบขอบเขตอาร์เรย์โดยอัตโนมัติการเพิ่มบัฟเฟอร์จะเป็นไปได้ในสถานการณ์ที่ผิดปกติเท่านั้น:

1. หากคุณเรียกรหัสเนทีฟผ่าน JNI
2. ใน JVM เอง (โดยปกติจะเขียนด้วย C ++)
3. ล่ามหรือคอมไพเลอร์ JIT ทำงานไม่ถูกต้อง (Java bytecode mandated bounds checks)

ภาษาที่มีการจัดการเช่น Java และ C # ไม่มีปัญหาเหล่านี้ แต่เครื่องเสมือนเฉพาะ (JVM / CLR / etc) ที่รันโค้ดอาจ

สำหรับเจตนาและวัตถุประสงค์ทั้งหมดเลขที่

Java มีการตรวจสอบขอบเขตอาร์เรย์ซึ่งจะตรวจสอบว่าข้อมูลไม่สามารถเข้าถึงได้จากพื้นที่ภายนอกอาร์เรย์ที่จัดสรร เมื่อมีผู้พยายามเข้าถึงพื้นที่ที่เกินขนาดของอาร์เรย์ArrayOutOfBoundsข้อยกเว้นจะถูกโยนทิ้ง

หากมีการบุกรุกบัฟเฟอร์อาจมาจากจุดบกพร่องใน Java Virtual Machine และจากความรู้ของฉันไม่ใช่พฤติกรรมที่ตั้งใจไว้ซึ่งเขียนในข้อกำหนดภาษา Java หรือข้อมูลจำเพาะของ Java Virtual Machine

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

http://secunia.com/advisories/25295

หรือดูคำแนะนำเก่า ๆ เหล่านี้เกี่ยวกับช่องโหว่ JDK และ JRE ก่อนหน้านี้:

• ช่องโหว่จำนวนเต็มและบัฟเฟอร์ล้นใน Java Runtime Environment (JRE) "unpack200" JAR Unpacking Utility อาจนำไปสู่การยกระดับสิทธิ์https://download.oracle.com/sunalerts/1020225.1.html

  ช่องโหว่จำนวนเต็มและบัฟเฟอร์ล้นใน Java Runtime Environment (JRE) ที่มีการคลายแพ็กเกจแอพเพล็ตและแอ็พพลิเคชัน Java Web Start โดยใช้ยูทิลิตี้การคลายแพ็ก JAR "unpack200" อาจอนุญาตให้แอพเพล็ตหรือแอปพลิเคชันที่ไม่น่าเชื่อถือสามารถเพิ่มสิทธิ์ได้ ตัวอย่างเช่นแอพเพล็ตที่ไม่น่าเชื่อถืออาจให้สิทธิ์ตัวเองในการอ่านและเขียนไฟล์ในเครื่องหรือเรียกใช้งานแอปพลิเคชันภายในเครื่องที่ผู้ใช้เรียกใช้แอพเพล็ตที่ไม่น่าเชื่อถือ

  Sun ยอมรับด้วยความขอบคุณ "regenrecht" ที่ทำงานร่วมกับ iDefense VCP ( http://labs.idefense.com/vcp/ ) และ Chris Evans จาก Google ที่แจ้งปัญหาเหล่านี้ให้เราทราบ

• มีการระบุช่องโหว่จำนวนมากใน Sun Java Development Kit (JDK) และ Java Runtime Environment (JRE) https://security.gentoo.org/glsa/200705-23

  ทีมรักษาความปลอดภัยของฟูจิตสึรายงานช่องโหว่ที่ไม่ระบุรายละเอียดซึ่งเกี่ยวข้องกับ "การใช้คลาสระบบอย่างไม่ถูกต้อง" นอกจากนี้ Chris Evans จากทีมรักษาความปลอดภัยของ Google ยังรายงานจำนวนเต็มล้นซึ่งส่งผลให้บัฟเฟอร์ล้นในตัวแยกวิเคราะห์ ICC ที่ใช้กับไฟล์ JPG หรือ BMP และการเรียกเปิด () ไปยัง / dev / tty ที่ไม่ถูกต้องเมื่อประมวลผลไฟล์ BMP บางไฟล์

บัฟเฟอร์ล้นในความหมายที่เข้มงวดของการเขียนทับสแต็กหรือฮีปเองจะต้องใช้อย่างใดอย่างหนึ่ง:

1. ข้อบกพร่องในเฟรมเวิร์ก (สิ่งเหล่านี้มีอยู่ในอดีตและอาจดีอีกครั้ง)
2. การใช้ JNI (โดยพื้นฐานแล้วจะไม่ใช้โค้ดที่มีการจัดการอีกต่อไป)

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

รูปแบบหลังนี้มีโอกาสน้อยกว่า แต่ฟังก์ชันการล้างสตริง sql ที่เขียนไม่ดีกระจายอยู่ทั่วไปซึ่งมีปัญหาเช่นนี้จะเป็นเป้าหมายที่เชิญชวน

เครื่องเสมือน Java (และ. Net) จับโค้ดที่พยายามเขียนนอกหน่วยความจำที่สงวนไว้ แอปพลิเคชันที่ไม่จัดการกับสิ่งนี้อย่างถูกต้องอาจทำให้เกิดปัญหาด้านความปลอดภัยได้ หากผู้ใช้ที่เป็นอันตรายสามารถเรียกใช้ข้อยกเว้นโดยการป้อนข้อมูลที่ไม่ถูกต้องก็สามารถทำการโจมตีแบบปฏิเสธบริการได้เช่นกัน

ดังที่ได้ระบุไปแล้ว Java มีขอบเขตการตรวจสอบการเข้าถึงหน่วยความจำทั้งหมดในฐานะภาษาและหากมีข้อผิดพลาดที่นี่ JVM เป็นความผิดปกติไม่ใช่โปรแกรม อย่างไรก็ตามสิ่งที่ควรสังเกตซึ่งเป็นข้อโต้แย้งที่คล้ายกับการรั่วไหลของหน่วยความจำใน Java ในขณะที่ไม่สามารถทุบสแต็กได้ ArrayOutOfBoundsException ในตำแหน่งที่ไม่ถูกต้องซึ่งไม่ได้รับการจัดการอย่างถูกต้องอาจยังคงทำให้ระบบของคุณเสียหาย

คุณอาจทำให้เกิดบัฟเฟอร์ล้นในโปรแกรม Java ได้หากคุณใช้โปรแกรม Java Native Interace (JNI) เพื่อเรียกใช้โค้ดภายนอกและโค้ดภายนอกมีปัญหาที่ใช้ประโยชน์ได้ สิ่งนี้ค่อนข้างผิดปกติเนื่องจากแอปพลิเคชันส่วนใหญ่หลีกเลี่ยงการใช้ JNI หากเป็นไปได้

เป็นไปได้สำหรับเมธอดในการเขียนลงในรายการที่ถูกต้องของอาร์เรย์ที่ไม่ได้ตั้งใจไว้โดยปกติจะผ่านการล้นจำนวนเต็ม

ตัวอย่างเช่นสิ่งต่อไปนี้ไม่เพียงพอที่จะตรวจสอบขอบเขต:

/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */

IIRC StringBufferเคยมีจุดบกพร่องเช่นนั้น แต่ไม่มีอะไรน่าสนใจที่คุณสามารถทำได้

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