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