Last night may have been a sleepless night for many programmers. In the early morning of December 10, the details of the remote code execution vulnerability of the Apache open source project Log4j were disclosed, and due to the widespread use of Log4j, this vulnerability can cause serious harm if exploited by attackers.
It is reported that Apache Log4j 2.x <= 2.14.1 versions will be affected. According to the Microstep Online Research Response Center, potentially affected applications include, but are not limited to: Spring-Boot-strater-log4j2, Apache Struts2, Apache Solr, Apache Flink, Apache Druid, Elasticsearch, Flume, Dubbo, Redis, Logstash, Kafka, etc. Many Internet companies have taken emergency measures overnight.
Log4j is an open source Java logging tool. Logging is mainly used to monitor the changes of variables in the code, and periodically log to files for other applications for statistical analysis; Track code runtime trajectories as a basis for future audits; Acts as a debugger in the integrated development environment, printing debugging information for code to files or consoles. Therefore, logging is very important for programmers.
Today, with an emphasis on reusable component development, Apache offers a powerful logging action pack, Log4j. Log4j can easily control whether log information is displayed, the output type, output mode, and output format of log information, and control the log generation process more finely, and it can be flexibly configured through configuration files without requiring a lot of code changes. Therefore, many Internet companies choose to use Log4j.
In 2014, Log4j 2 was released. Log4j 2 is a major upgrade to Log4j that completely rewrites the logging implementation of log4j. Log4j 2 provides many of the improvements available in Logback, while fixing some inherent issues in the Logback architecture, which has been updated to version 2.15.0.
Log4j2 also supports SLF4J, which automatically reloads log configurations and supports advanced filtering options. It also allows lazy evaluation of log statements based on lambda expressions, provides asynchronous loggers for low-latency systems, and provides a garbage-free mode to avoid any delays caused by garbage collector operations. Through other language interfaces, enterprises can also use the same in C, C++, . Use Log4j in Net, PL/SQL programs.
The vulnerability is caused by the lookup feature provided by Log4j 2, which allows developers to read the configuration of the corresponding environment through some protocols. However, in the process of implementation, the input is not strictly judged, resulting in vulnerabilities. “Microstep Online Research Response Center” made a bug reproduction:
Flink job repair planAccording
to zhisheng’s use of Log4j2 in various versions of Flink, it is found that only Flink 1.11 and above introduces Log4j2, and versions below 1.11 use Log4j. It is not affected this time, so you can not upgrade.
The easiest way to do this is to add the following configuration to the flink-conf.yaml file: env.java.opts:
-Dlog4j2.formatMsgNoLookups=true
Zhisheng pro-test can take effect, after updating the configuration, the new job will be fixed by default to avoid vulnerabilities, but the old job needs to be restarted, for companies with more production operations, you need to restart carefully, remember to restart without affecting the user, to avoid failures caused by small mistakes!
The Flink community also updated the solution to this vulnerability yesterday: https://issues.apache.org/jira/browse/FLINK-25240, update Log4J2 to a new version. However, this is only for later versions, users upgrade to a larger version, or users can directly replace the log4j related dependency jar packages under the flink lib directory, but it is recommended to test more to avoid incompatibility problems.
end
public number (zhisheng ) reply to Face, ClickHouse, ES, Flink, Spring, Java, Kafka, Monitor keywords such as to view more articles corresponding to keywords. like + Looking, less bugs 👇
