หากถูกโจมตี ข้อบกพร่องเหล่านี้อาจทำให้ผู้โจมตีเข้าถึงข้อมูลที่ละเอียดอ่อนโดยไม่ได้รับอนุญาต หรือก่อให้เกิดปัญหาโดยทั่วไป
มีการระบุจุดอ่อน (อยู่ในรายการแล้วภายใต้ CVE-2022-37454) en การใช้งานฟังก์ชันแฮชเข้ารหัส SHA-3 (Keccak) มีให้ในแพ็คเกจ XKCP (แพ็คเกจรหัส Keccak แบบขยาย)
ช่องโหว่ที่ระบุ อาจทำให้บัฟเฟอร์ล้นได้ ระหว่างการประมวลผลข้อมูลที่เกิดขึ้น ปัญหาเกิดจากข้อบกพร่องในโค้ดของการใช้งาน SHA-3 โดยเฉพาะ ไม่ใช่ช่องโหว่ในอัลกอริทึม
บรรจุภัณฑ์ เอ็กซ์เคซีพี ได้รับการขนานนามว่าเป็นการใช้งาน SHA-3 อย่างเป็นทางการซึ่งพัฒนาขึ้นด้วยความช่วยเหลือของทีมพัฒนา Keccak และ ใช้เป็นพื้นฐานในการทำงานกับ SHA-3 ในภาษาการเขียนโปรแกรมต่างๆ (เช่น รหัส XKCP ใช้ในโมดูล Python hashlib, แพ็คเกจ Ruby Digest-sha3 และฟังก์ชัน PHP hash_*)
ตามที่ผู้วิจัยระบุปัญหา สามารถใช้ช่องโหว่เพื่อละเมิดคุณสมบัติการเข้ารหัสได้ ของฟังก์ชันแฮชและค้นหาพรีอิมเมจแรกและตัวที่สอง ตลอดจนระบุการชนกัน
สาเหตุของความผิดพลาดในการแบ่งเซ็กเมนต์คือสคริปต์จะพยายามเขียนข้อมูลไปยังบัฟเฟอร์มากกว่าที่มันจะเก็บได้ ช่องโหว่ดังกล่าวเรียกว่าบัฟเฟอร์โอเวอร์โฟลว์ ซึ่ง OWASP อธิบายว่า "อาจเป็นรูปแบบที่เป็นที่รู้จักดีที่สุดของช่องโหว่ด้านความปลอดภัยของซอฟต์แวร์"
รหัสรุ่นเล็ก ๆ จะทำให้เกิดการวนซ้ำไม่สิ้นสุด: เพียงแทนที่ 4294967295 ด้วย 4294967296 สังเกตความคล้ายคลึงกันกับ CVE-2019-8741 ซึ่งเป็นช่องโหว่อื่นที่ฉันพบว่าส่งผลต่อเฟิร์มแวร์ของอุปกรณ์ Apple กว่า 1.400 พันล้านเครื่องซึ่งทำให้เกิดการวนซ้ำไม่สิ้นสุด
ด้วย, มีการประกาศการสร้างการใช้ประโยชน์จากต้นแบบ, que อนุญาตให้ใช้รหัสเมื่อคำนวณ hash จากไฟล์ที่ออกแบบมาเป็นพิเศษ ช่องโหว่นี้ยังสามารถใช้เพื่อโจมตีอัลกอริธึมการตรวจสอบลายเซ็นดิจิทัลโดยใช้ SHA-3 (เช่น Ed448) รายละเอียดของวิธีการโจมตีคาดว่าจะเผยแพร่ในภายหลัง หลังจากการลบช่องโหว่ทั่วไป
พฤติกรรมประเภทนี้ไม่ควรเกิดขึ้นในภาษาที่ "ปลอดภัย" เช่น Python และ PHP เนื่องจากพวกเขาตรวจสอบว่าการดำเนินการอ่านและเขียนทั้งหมดอยู่ภายในขอบเขตของบัฟเฟอร์ อย่างไรก็ตาม ปัญหาคือมีช่องโหว่ในภาษา C ที่ "ไม่ปลอดภัย"...
ยัง ยังไม่ชัดเจนว่าช่องโหว่ดังกล่าวส่งผลกระทบต่อแอปพลิเคชันที่มีอยู่ในทางปฏิบัติอย่างไรเนื่องจากเพื่อให้ปัญหาปรากฏในโค้ด ต้องใช้การคำนวณแฮชแบบวนซ้ำบนบล็อก และหนึ่งในบล็อกที่ประมวลผลต้องมีขนาดประมาณ 4 GB (อย่างน้อย 2^32 – 200 ไบต์)
เมื่อประมวลผลข้อมูลอินพุตพร้อมกัน (โดยไม่มีการคำนวณแฮชตามลำดับส่วน) ปัญหาจะไม่ปรากฏขึ้น เพื่อเป็นวิธีการป้องกันที่ง่ายกว่า เราเสนอให้จำกัดขนาดสูงสุดของข้อมูลที่เกี่ยวข้องกับการคำนวณแฮชซ้ำหนึ่งครั้ง
โค้ดที่มีช่องโหว่นี้เผยแพร่ในเดือนมกราคม 2011 ดังนั้นจึงต้องใช้เวลากว่าทศวรรษกว่าจะหาช่องโหว่นี้ได้ ดูเหมือนเป็นการยากที่จะค้นหาช่องโหว่ในการใช้งานการเข้ารหัส แม้ว่าช่องโหว่เหล่านี้จะมีบทบาทสำคัญในการรักษาความปลอดภัยโดยรวมของระบบ (บางทีผู้คนอาจไม่ได้มองหาช่องโหว่ดังกล่าวด้วยซ้ำ เนื่องจากทั้งช่องโหว่ใน XKCP หรือช่องโหว่ของ Apple ที่กล่าวถึงข้างต้นไม่เข้าเกณฑ์สำหรับโปรแกรมหาจุดบกพร่องใดๆ!)
ช่องโหว่ เกิดจากข้อผิดพลาดในการประมวลผลบล็อกของข้อมูลอินพุต. เนื่องจากการเปรียบเทียบค่าที่ไม่ถูกต้องกับประเภท "int" จึงมีการกำหนดขนาดที่ไม่ถูกต้องของข้อมูลที่ค้างอยู่ ซึ่งทำให้คิวถูกเขียนออกจากบัฟเฟอร์ที่จัดสรร
โดยเฉพาะอย่างยิ่ง กล่าวได้ว่า เมื่อเปรียบเทียบนิพจน์ «PartialBlock + อินสแตนซ์ -> byteIOIndex« ซึ่งด้วยค่าขนาดใหญ่ของส่วนประกอบทำให้เกิดจำนวนเต็มล้น นอกจากนี้ยังมี typecast ที่ไม่ถูกต้อง "(unsigned int)(dataByteLen - i)" ในโค้ด ทำให้เกิดโอเวอร์โฟลว์บนระบบที่มีประเภท size_t 64 บิต
ในที่สุด หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติมคุณสามารถตรวจสอบรายละเอียดได้ในไฟล์ ลิงค์ต่อไปนี้