Спешната корекция за прословутата уязвимост в Java библиотеката Log4j не е надеждна. Apache Software Foundation пуска нова версия, за да коригира уязвимостта веднъж завинаги.
Уязвимост в изключително популярна библиотека за Java разтърсва глобалния ИТ пейзаж. Смята се, че библиотеката съществува в повечето корпоративни среди.
Log4j се използва главно за регистриране. Събитията в приложенията могат да бъдат регистрирани с бележки. Помислете за разпечатка на данните за влизане след опит за влизане. Или, в случай на уеб приложение в Java, името на браузъра, с който потребителят се опитва да се свърже.
Последните примери са често срещани. И в двата случая външен потребител влияе на журнала, който Log4j извежда. Възможно е да се злоупотребява с това влияние. Регистратурите на всяка версия на Log4j между 13 септември 2013 г. и 5 декември 2021 г. могат да инструктират Java приложенията да изпълняват кода от отдалечен сървър на локално устройство.
От 2013 г. Log4j обработва API: JNDI или интерфейс за именуване и директория на Java. Добавянето на JNDI позволява на Java приложение да изпълнява код от отдалечен сървър на локално устройство. Програмистите инструктират, като добавят един ред с подробности за отдалечения сървър в приложение.
Проблемът е, че не само програмистите могат да добавят правилото към приложенията. Да предположим, че Log4j регистрира потребителските имена на опитите за влизане. Когато някой въведе гореспоменатия ред в полето за потребителско име, Log4j стартира реда и Java приложението интерпретира команда за изпълнение на кода на посочения сървър. Същото важи и за случаите, когато Log4j регистрира HTTPS заявка. Ако промените името на браузъра на реда, Log4j стартира реда, индиректно го инструктирайки да изпълнява кода по желание.
Спешният пластир също може да бъде опасен
На 9 декември уязвимостта излезе наяве в голям мащаб. Apache Software Foundation, разработчикът на Log4j, пусна спешна корекция (2.15), за да коригира уязвимостта. Оттогава е основен приоритет за доставчиците на софтуер да обработват версия 2.15 и да предоставят корекция за организациите.
Въпреки това организацията за сигурност LunaSec заявява, че пластирът не е напълно водонепропусклив. Остава възможно да се коригира настройка и да се изпълняват регистрирани JNDI команди.
Моля, обърнете внимание: съответната настройка трябва да се регулира ръчно, така че немодифицираните варианти на 2.15 наистина са безопасни. Въпреки това Luna Sec препоръчва на доставчиците и организациите да актуализират до Log4j 2.16. 2.16 беше публикуван от Apache Software Foundation в отговор на LunaSec. Новата версия напълно премахва уязвимата настройка, което прави невъзможно създаването на условия за злоупотреба.