Log4j CVE-2021-44228

Решения

Подумайте, действительно ли вам нужен Log4j2 Core. Скорее всего, вашему собственному коду (или какой-либо сторонней библиотеке, от которой вы зависите) требуется лишь фасад Logging API от Log4j - но он может вести журнал в другой серверный компонент. Поэтому вы можете просто полностью исключить зависимость org.apache.logging.log4j:log4j-core.

Используйте один из нескольких доступных "мостов Logging API", чтобы соединить (только) log4j-api с другим серверным компонентом реализации ведения журнала:

1. Log4j2-SLF4j-Logback с использованием log4j-to-slf4j

2. Log4j2-to-JUL из LOG4J2-3282, автором которого являюсь я, как показано на https://github.com/vorburger/Learning-Log4j2.

Это особенно актуально, если у вас или у вашего облачного провайдера уже есть инфраструктура для соответствующего серверного компонента:

• Google Cloud Logging Logback Appender, см. на GitHub, также с интеграцией Spring Framework

Предыстория

• https://logging.apache.org/log4j/2.x/security.html
• https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Обнаружение и сканирование, поверхность атаки

• https://github.com/github/codeql/pull/7354
• https://github.com/google/tsunami-security-scanner-plugins/issues/219
• https://github.com/YfryTchsGD/Log4jAttackSurface (с мемами)

Меры по смягчению

• https://github.com/apache/logging-log4j2/pull/608
• https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
• https://community.openhab.org/t/openhab-and-the-log4j-security-vulnerability/129901
• https://github.com/vorburger/MariaDB4j/issues/509

Эксплойт

• https://www.lunasec.io/docs/blog/log4j-zero-day/#exploit-steps