Още една уязвимост в Log4j 2. Проблемите в Log4j засягат 8% от Maven-пакетите.

В библиотеката 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 декември на организациите е предписано да отчетат свършената работа. За улесняване на откритията на проблематичните системи е изготвен списък с продукти, в които е потвърдена проява на уязвимост (в списъка има над 23000 приложения).

Източник: opennet.ru