Для уязвимости в Log4j вышло второе исправление

На прошлой неделе Apache выпустила новую версию 2.15 своей утилиты журналирования Log4j, предназначенную для устранения нашумевшей уязвимости Log4Shell ( CVE-2021-44228 ), позволяющей через интернет взламывать серверы и приложения на базе Java.

Однако это обновление исправляло уязвимость только частично. В версии 2.15 по умолчанию был отключен лишь один аспект функционала JNDI по поиску сообщений. Теперь же вышло второе исправление 2.16, по умолчанию отключающее всю поддержку JNDI и полностью удаляющее обработку поиска сообщений.

Выпуск второго обновления был необходим, поскольку версию 2.15 по-прежнему можно проэксплуатировать при определенных незаводских конфигурациях. Данная проблема получила собственный идентификатор CVE-2021-45046 .

Apache признала, что JNDI «имеет серьезные проблемы с безопасностью», поэтому было принято решение отключить его по умолчанию.

«CVE-2021-44228 показала нам, что у JNDI серьезные проблемы с безопасностью. Хотя мы устранили то, что нам было известно, для большей безопасности пользователей было решено полностью отключить его по умолчанию, тем более что большинство вряд ли вообще пользуются им», – сообщила Apache.

В связи с этим в версии 2.16.0 JNDI выключен. JNDI представляет собой API, используемый утилитой Log4j для извлечения объектов с удаленных серверов с целью их использования в записях журнала.

При включенном JNDI злоумышленники могут заставить утилиту Log4j извлечь Java-код с подконтрольного им сервера и выполнить его, скомпрометировав устройство. Для этого злоумышленники должны ввести определенным образом созданный текст, например, в имя учетной записи приложения или в поисковый запрос сайта. При внесении в журнал утилитой Log4j это спровоцирует удаленное выполнение кода.

Java Naming and Directory Interface (JNDI) – набор Java API, организованный в виде службы каталогов, который позволяет Java-клиентам открывать и просматривать данные и объекты по их именам. Как любое другое Java API, как набор интерфейсов, JNDI не зависит от нижележащей реализации. В дополнение к этому, он предоставляет реализацию service provider interface (SPI), которая позволяет службам каталогов работать в паре с каким-либо фреймворком.