У бібліятэцы Log4j 2 выяўлена яшчэ адна ўразлівасць (CVE-2021-45105), якая ў адрозненне ад двух мінулых праблем, аднесена да катэгорыі небяспечных, але не крытычных. Новая праблема дазваляе выклікаць адмову ў абслугоўванні і праяўляецца ў выглядзе зацыклення і аварыйнага завяршэння пры апрацоўцы пэўных радкоў. Уразлівасць ухіленая ў апублікаваным некалькі гадзін назад выпуску Log4j 2.17. Небяспека ўразлівасці згладжвае тое, што праблема выяўляецца толькі на сістэмах з Java 8.
Уразлівасці схільныя сістэмы, выкарыстоўвалыя пры азначэнні фармату высновы ў лог кантэкстныя запыты (Context Lookup), такія як ${ctx:var}. У версіях Log4j, пачынальна з 2.0-alpha1 і сканчаючы 2.16.0, адсутнічала абарона ад некантралюемай рэкурсіі, што дазваляла атакаваламу праз маніпуляцыі са значэннем, выкарыстоўваным пры падстаноўцы, выклікаць зацыкленне, якое прыводзіць да вычарпання месца ў стэку і аварый. У прыватнасці, праблема ўзнікала пры падстаноўцы такіх значэнняў, як "${${::-${::-$${::-j}}}}".
Дадаткова можна адзначыць, што даследнікі з кампаніі Blumira прапанавалі варыянт нападу на ўразлівыя Java-прыкладанні, не якія прымаюць вонкавыя сеткавыя запыты, напрыклад, можна атакаваць такім чынам сістэмы распрацоўнікаў або карыстачоў Java-прыкладанняў. Сутнасць метаду ў тым, што пры наяўнасці на сістэме карыстальніка ўразлівых Java-працэсаў, якія прымаюць сеткавыя злучэнні толькі з лакальнага хаста (localhost), ці апрацоўваюць RMI-запыты (Remote Method Invocation, 1099 порт), напад можа быць здзейснена JavaScript-кодам, выкананым пры адкрыцці карыстальнікам у браўзэры шкоднаснай старонкі. Для арганізацыі злучэння з сеткавым портам Java-прыкладанні пры падобнай атацы выкарыстоўваецца API WebSocket, да якога ў адрозненне ад HTTP-запытаў не прымяняюцца абмежаванні same-origin (WebSocket таксама можа выкарыстоўвацца сканавання сеткавых партоў на лакальным хасце з мэтай вызначэння наяўных сеткавых апрацоўшчыкаў).
Таксама цікавасць уяўляе апублікаваныя кампаніяй Google вынікі адзнакі ўразлівасці бібліятэк, злучаных залежнасцямі з Log4j. Па дадзеных Google, праблема закранае 8% ад усіх пакетаў у рэпазітары Maven Central. У прыватнасці, уразлівасці апынуліся схільныя 35863 Java-пакетаў, злучаных з Log4j прамымі і ўскоснымі залежнасцямі. Пры гэтым Log4j выкарыстоўваецца ў якасці прамой залежнасці першага ўзроўня толькі ў 17% выпадкаў, а ў 83% ахопленых уразлівасцю пакетаў прывязка ажыццяўляецца праз прамежкавыя пакеты, залежныя ад Log4j, т.е. залежнасці другога і больш высокага ўзроўню (21% - другога ўзроўню, 12% - трэцяга, 14% - чацвёртага, 26% - пятага, 6% - шостага). Тэмпы выпраўлення ўразлівасці пакуль пакідаюць жадаць лепшага, праз тыдзень пасля выяўлення ўразлівасці з 35863 выяўленых пакетаў праблема ўхіленая пакуль толькі ў 4620, г.зн. у 13%.
Тым часам, Агенцтва па кібербяспецы і абароне інфраструктуры ЗША апублікавала экстраную дырэктыву, якая абавязвае федэральныя агенцтвы вырабіць вызначэнне інфармацыйных сістэм, схільных уразлівасці ў Log4j, і да 23 снежня вырабіць усталёўку абнаўленняў, якія блакуюць праблему. Да 28 снежня арганізацыям загадана даць справаздачу аб праведзенай працы. Для спрашчэння выяўлення праблемных сістэм падрыхтаваны спіс прадуктаў, у якіх пацверджана праява ўразлівасці (у спісе больш за 23 тысячы прыкладанняў).
Крыніца: opennet.ru