As one of the top programming languages, Java has been active in enterprise software development for 25 years. Some people keep proclaiming that Java is dead, while others insist that Java is alive and well. Recently, it has been reported that the Log4j 2 vulnerability is once again “killing” Java. We used to joke that the Java Museum was like a cemetery, documenting every “death.”

Last week, the tech world was rocked by the Log4j 2 vulnerability, with security companies Posting information about the vulnerability and offering various temporary fixes. Other bloggers have also published articles that teach us how to find vulnerable places and defend ourselves accordingly. Plenty of posts followed, discussing unnecessary defensive techniques.

The log4j 2 team has released a new version 2.16.0 to strengthen the vulnerability defense mechanism. Log4j 2 is an open source logging system based on Java, so when the epic vulnerability was exposed, it was claimed that log4j 2 vulnerabilities would “kill” Java again. Java has been “killed” so many times that it is like opening a cemetery to record every “death”.

This article provides a brief introduction to the Java ecosystem, explaining what a logging framework is, where it is used, and why, as well as how teams should observe and control the behavior of the JVM.

1. What security should Java developers do

Rapid patching of the JDK and libraries is the most effective technique available to prevent the vast majority of large-scale hacks.

Patch library files (required)

When there are bugs in the code base, the most effective technique is to patch to remove the bugs. If the library files are not patched, the application is likely to be hacked and the attacker will gain full access to the system and its data.

In any case, patching usually works.

The logging framework may come from any dependency and may be introduced by another library (that is, passing dependencies) rather than being added by a developer (that is, direct dependencies). Dependency analysis tools, such as Contrast Community Edition, can be used to detect dependencies and other custom vulnerabilities.

There are also open source tools for analyzing dependencies, such as Maven dependency: Tree and Gradle dependency trees. Ides such as NetBeans also provide dependency diagram visualization tools.

For log4j2 vulnerabilities, you must upgrade to 2.15.0 or later.

Patch JRE to upgrade to Java security baseline (recommended, periodically)

Each major Java release maintains a security baseline. This security baseline is constantly moving forward as the JDK provides patches with new security improvements every quarter. Java below the security baseline contains known security issues and should be upgraded.

This is standard security best practice and is not directly related to the Log4j 2 vulnerability, nor will it be fixed.

Teams can use the Foojay Disco API to automatically monitor security baselines and update systems in a timely manner. Developers can combine this update with GitHub operations to ensure that the latest security updates are used every time they build code. If a security incident occurs, upgrade the JRE immediately, rebuild and redeploy the code at the same time. The following test matrix contains GitHub operations of this kind:

Github.com/foojayio/di…

The update time of the Java security baseline is January, April, July, and October, and Tuesday around the 17th. Details are included in the Oracle Critical Patch Update Program (www.oracle.com/security-al… Bug group (foojay-io /pedia/secur… Unplanned security updates will also be provided. This is not the case with the Log4j 2 vulnerability.

The following configuration demonstrates how to use the Java 11 security baseline:

jobs:java11:runs-on: ${{ matrix.os }}strategy:matrix:os: [ubuntu-latest, macos-latest, windows-latest]update: [x]package: [jdk, jre]fail-fast: falsemax-parallel: 4name: ${{matrix.package}} 11.0.${{matrix.update}}, ${{matrix. OS}}steps:- uses: actions/checkout@v1- name: Set up JDK 11 Zuluuses: foojayio/setup-java@discowith:java-package: ${{ matrix.package }}java-version: ${{matrix.update}}distro: zulu-name: java-versionrun: java-versionCopy the code

Regularly detect custom security vulnerabilities (recommended)

Automated security tools can catch security vulnerabilities without requiring security expertise. Integrating such security tools into Java applications enables security monitoring and logging of security information. While some tools determine vulnerability based on the number of dependencies, this approach reports on the combination of these dependency libraries based on the dependency information and determines whether the combination is secure.

For example, the integration analyzer not only checks for the presence or absence of log4j2 and its version, but also determines whether an attacker can control remote log input.

In addition, free profilers such as Contrast Community Edition are able to catch Log4j 2 in real time and many other security vulnerabilities, such as:

  • Does your application’s Hibernate, JBDC, or any other place contain SQL injection issues?

  • Can remote users control any input sent to Runtime.exec, i.e., is there a command injection vulnerability?

  • What encryption algorithms does the application use, where does it use them, and does it meet appropriate standards?

  • Did a developer accidentally introduce a security vulnerability, such as OGNL input parsing, when using multiple libraries together?

  • And other application-specific security vulnerabilities.

Monitor security events using the JDK Flight Recorder

JDK Flight Recorder is a performance analysis tool included in modern OpenJDK distributions that not only generates some security information, but is very inexpensive. Teams can use the JDK Flight Recorder to record many IO operations, such as which files are accessed by the JRE or which classes are deserialized.

By using the JDK Flight Recorder to monitor Java application events and stream them to a Security Information and Event Management (SIEM) system, The Java team can then monitor for abnormal behavior and check that individual classes are secure through Java deserialization filters that prevent vulnerabilities.

2. Which safety measures don’t have much effect

For log4j 2 vulnerabilities, network-based defenses and tools such as the Web Application Firewall (WAF) may be effective in the short term, but they are usually not very effective and the work is very heavy.

  • Cyber defense is not effective. There’s a meme circulating on the Internet, a photoshopped photo of a car that includes an injection tool on its license plate. The point of this meme is that every developer knows that the license plate number is analyzed by computer vision and recorded in a log. The data that makes up the injection does not appear at the network layer. Again, most applications use different parts of the data, decode the data, and record various information. No networking tool can match enough patterns to detect security problems.

  • Blocking an attacker’s IP through observation and tracking is not particularly effective. While some teams may maintain a list of attackers, AWS ips are called elastic because they change regularly, so even if you block an IP, it can be unlocked again after a while, or quickly attacked by a different IP.

The effect of system properties and dynamic patches is mediocre

There are several patches and system properties that control log4j 2’s behavior and prevent attacks. These patches and system properties can be considered in cases where libraries are not up to date, or where the team is trying to update dependencies over time.

There are two related Java system properties:

-Dcom.sun.jndi.rmiobject.trustURLCodebase=false-Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false
Copy the code

Setting both properties to false prevents remote attacks.

There is also a dynamic patch that can connect to and patch a running JVM. This patch must be applied every time the JVM starts. While these two methods are useful, updating the library is relatively simple.

3. How does Java handle logging

Java developers can typically choose from several logging systems and recording methods. Over the years, as the community has grown, many logging frameworks have become available to work together:

  • The System Logger (2017, recommended) is a logging System introduced in JDK 9. It improves the JDK Logger API and provides a logging method similar to SLF4j that redirects JDK logs to the logging system of the application team’s choice.

  • JDK Logger (2004) is a logging system introduced in Java 1.4. This logging system has become popular due to its heavy use in the JDK, but the API is a bit clunky. While this logging system is good, it’s not as good as other frameworks.

  • Log4j and Log4j2, community recommended logging systems, improve their apis so that development teams can more easily control what is logged and how data is logged at all levels.

  • Logback and SLF4j are also popular logging systems. SLF4J is a simple logging approach that helps teams work with many logs. Library maintainers can export logs to SLF4J, and application developers can then configure which underlying logging systems they will use for uniform output. In addition, SLF4J has established a good API to minimize dependencies.

  • JBoss Logger is another popular logging system in the JBoss ecosystem. The system has good performance and high speed. It now supports other popular frameworks, such as Quarkus.

  • Apache Commons-Logging (launched in 2002) was born before the JDK Logging system and has inspired many apis. The last version was released in 2014, and other apis aimed at supporting good logging have since been adopted.

Recommended log system for 2022

The fewer dependencies the better, and the newer the project, the better, so we can consider the System Logger.

Some projects have a large number of dependencies, but the advantage is that they use the same logging tools as most of the dependencies, but in a different way.

If you don’t have a logging System, consider The System Logger, a JDK logging tool with a good API.

What exactly does a logging system do?

The logging framework enables application owners to see log messages, timestamps, thread names, and other data in a common format.

In addition, the team can redirect different output to different locations without even having to display it, for example, you can send access logs to one file, send system reports elsewhere, and then choose to display all levels of log information, or dynamically view debugging information for a library.

PS: In case you can’t find this article, please click “like” to browse and find it