On the morning of December 10, the details of the remote code execution vulnerability of Apache open source project Log4j2 were published. The threat level of the vulnerability is: critical.

Log4j2 is a Java-based logging tool. It rewrites the Log4j framework and introduces a number of rich features that allow users to control the destination of log messages to consoles, files, GUI components, and so on. In addition, by defining the level of each log information, users can control the log generation process in detail.

Log4j is one of the most widely used Java logging frameworks in the world today. The vulnerability also affects many of the most widely used open source components in the world, such as Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and more. Because this vulnerability is easy to exploit, once an attacker takes advantage of this vulnerability, he can execute any code on the target server, causing great harm to the attacked.

Vulnerability details

The main cause of this vulnerability is the JNDI injection vulnerability in the lookup function contained in Log4j2, which can help developers read the configuration in the corresponding environment through some protocols. Vulnerability trigger method is very simple, as long as the log content contains the keyword ${, then the content contained in it can be replaced as a variable, the attacker can execute any command without any permission.

The version affected by the vulnerability is Apache Log4j 2.x <= 2.14.1

If you use the following applications, you will also be affected by this vulnerability:

  • Spring-Boot-strater-log4j2

  • Apache Struts2

  • Apache Solr

  • Apache Flink

  • Apache Druid

  • ElasticSearch

  • flume

  • dubbo

  • logstash

  • kafka

Bug fix

The vendor has released a new version of log4J-2.15.0-rc2, which has fixed the vulnerability. I hope you can upgrade to the new version soon.

Official link: github.com/apache/logg…

If it is not convenient for you to upgrade the version, you can also perform the following operations to upgrade the version as soon as possible:

  • Modify the JVM parameter – Dlog4j2. FormatMsgNoLookups = true

  • Modify the configuration log4j2. FormatMsgNoLookups = True

  • Set the system environment variable FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS to true

Whether it was the vulnerability of Apach Shiro’s cookie persistence parameter rememberMe encryption algorithm last year or the Fastjson notification of remote code execution vulnerability last May. There may always seem to be problems with cyber security, but finding and fixing a vulnerability is itself a security upgrade. Standing still will be breached quickly, only continuous updates and upgrades is the real network security.

Recommended reading

Margin collapse of CSS box

Popular play kill and SaaS indissoluble bond