ช่องโหว่อื่นได้รับการระบุในไลบรารี Log4j 2 (CVE-2021-45105) ซึ่งได้รับการจัดประเภทว่าเป็นอันตราย แต่ไม่สำคัญ ไม่เหมือนกับปัญหาสองข้อก่อนหน้านี้ ปัญหาใหม่ช่วยให้คุณสามารถทำให้เกิดการปฏิเสธการให้บริการและแสดงออกมาในรูปแบบของการวนซ้ำและการขัดข้องเมื่อประมวลผลบางบรรทัด ช่องโหว่ได้รับการแก้ไขใน Log4j 2.17 ที่เผยแพร่เมื่อไม่กี่ชั่วโมงก่อน อันตรายจากช่องโหว่นั้นได้รับการบรรเทาลงด้วยข้อเท็จจริงที่ว่าปัญหาปรากฏเฉพาะบนระบบที่มี Java 8 เท่านั้น
ช่องโหว่นี้ส่งผลกระทบต่อระบบที่ใช้การสืบค้นตามบริบท (การค้นหาบริบท) เช่น ${ctx:var} เพื่อกำหนดรูปแบบเอาต์พุตของบันทึก Log4j เวอร์ชันตั้งแต่ 2.0-alpha1 ถึง 2.16.0 ขาดการป้องกันการเรียกซ้ำที่ไม่สามารถควบคุมได้ ซึ่งทำให้ผู้โจมตีสามารถจัดการค่าที่ใช้ในการทดแทนเพื่อทำให้เกิดลูป ส่งผลให้พื้นที่สแต็กหมดลงและเกิดข้อขัดข้อง โดยเฉพาะอย่างยิ่งปัญหาเกิดขึ้นเมื่อแทนที่ค่าเช่น "${${::-${::-$${::-j}}}}"
นอกจากนี้ สังเกตได้ว่านักวิจัยจาก Blumira ได้เสนอทางเลือกในการโจมตีแอปพลิเคชัน Java ที่มีช่องโหว่ซึ่งไม่ยอมรับคำขอเครือข่ายภายนอก ตัวอย่างเช่น ระบบของนักพัฒนาหรือผู้ใช้แอปพลิเคชัน Java สามารถถูกโจมตีด้วยวิธีนี้ สาระสำคัญของวิธีการนี้คือ ถ้ามีกระบวนการ Java ที่มีช่องโหว่บนระบบของผู้ใช้ที่ยอมรับการเชื่อมต่อเครือข่ายจากโฮสต์ในพื้นที่เท่านั้น หรือประมวลผลคำขอ RMI (การเรียกใช้วิธีการระยะไกล พอร์ต 1099) การโจมตีสามารถทำได้โดยใช้โค้ด JavaScript ที่ดำเนินการ เมื่อผู้ใช้เปิดเพจที่เป็นอันตรายในเบราว์เซอร์ของตน ในการสร้างการเชื่อมต่อกับพอร์ตเครือข่ายของแอปพลิเคชัน Java ในระหว่างการโจมตีนั้น WebSocket API จะถูกนำมาใช้ ซึ่งแตกต่างจากคำขอ HTTP ตรงที่ไม่มีการใช้ข้อจำกัดจากแหล่งกำเนิดเดียวกัน (WebSocket ยังสามารถใช้เพื่อสแกนพอร์ตเครือข่ายในเครื่องได้ โฮสต์เพื่อกำหนดตัวจัดการเครือข่ายที่พร้อมใช้งาน)
สิ่งที่น่าสนใจคือผลลัพธ์ที่เผยแพร่โดย Google เกี่ยวกับการประเมินช่องโหว่ของไลบรารีที่เกี่ยวข้องกับการพึ่งพา Log4j จากข้อมูลของ Google ปัญหาดังกล่าวส่งผลกระทบต่อ 8% ของแพ็คเกจทั้งหมดในพื้นที่เก็บข้อมูล Maven Central โดยเฉพาะอย่างยิ่ง แพ็คเกจ Java 35863 รายการที่เชื่อมโยงกับ Log4j ผ่านการพึ่งพาทั้งทางตรงและทางอ้อมถูกเปิดเผยต่อช่องโหว่ ในเวลาเดียวกัน Log4j จะถูกใช้เป็นการพึ่งพาระดับแรกโดยตรงเพียง 17% ของกรณี และใน 83% ของแพ็คเกจที่ได้รับผลกระทบ การรวมจะดำเนินการผ่านแพ็คเกจระดับกลางที่ขึ้นอยู่กับ Log4j เช่น การเสพติดระดับที่สองและสูงกว่า (21% - ระดับที่สอง, 12% - สาม, 14% - ที่สี่, 26% - ห้า, 6% - ที่หก) ความเร็วในการแก้ไขช่องโหว่ยังคงเป็นที่ต้องการอย่างมาก หนึ่งสัปดาห์หลังจากระบุช่องโหว่ จากแพ็คเกจที่ระบุ 35863 รายการ ปัญหาได้รับการแก้ไขแล้วเพียง 4620 รายการเท่านั้น กล่าวคือ ที่ 13%
ในขณะเดียวกัน หน่วยงานรักษาความปลอดภัยทางไซเบอร์และโครงสร้างพื้นฐานของสหรัฐอเมริกาได้ออกคำสั่งฉุกเฉินโดยกำหนดให้หน่วยงานรัฐบาลกลางระบุระบบข้อมูลที่ได้รับผลกระทบจากช่องโหว่ Log4j และติดตั้งการอัปเดตที่บล็อกปัญหาภายในวันที่ 23 ธันวาคม ภายในวันที่ 28 ธันวาคม องค์กรต่างๆ จะต้องรายงานผลงานของตน เพื่อให้การระบุระบบที่มีปัญหาง่ายขึ้น จึงได้จัดทำรายการผลิตภัณฑ์ที่ได้รับการยืนยันว่ามีช่องโหว่ (รายการดังกล่าวประกอบด้วยแอปพลิเคชันมากกว่า 23 รายการ)
ที่มา: opennet.ru