December 13, 2021

Apache Log4j (Java) Remote Code Execution 0-Day Flaw

Apache Log4j (Java) Remote Code Execution 0-Day Flaw, Log4Shell (CVE-2021-44228)

VENDOR ADVISORY:
https://logging.apache.org/log4j/2.x/index.html 

PLATFORMS AFFECTED:
Any Java based software/service that incorporates Log4j versions starting from 2.0-beta9 and prior to 2.15.0

SEVERITY:
Urgent

CRITICAL IMPACT:
Unauthenticated remote code execution.

There is a critical remote code execution vulnerability in Apache Log4j. Log4j is a popular Java library incorporated into millions of Java applications from many different vendors. This logic flaw in how untrusted input is handled allows for trivial and reliable exploitation as well as earning a perfect 10 out of 10 from the Common Vulnerability Scoring System (CVSS) [1]. This is one of the most serious security flaws in the last decade.

Given the high severity and absent confirmation that your software is not using an affected version of Log4j, we suggest contacting your vendors to verify whether remediation is required.

WHAT YOU HAVE TO DO:

This is a newly discovered flaw and software vendors are working quickly to provide patches or mitigation for this flaw. If you are affected by this vulnerability, verify with your software vendor for patches.

If a patch is not yet available for your software:

Our Information Security Office (CMU ISO) has shared some general mitigation strategies if patches are not yet available for your particular Java-based software:

1. If your software uses Log4j >= 2.10, then set the JAVA_OPTS to include “-Dlog4j2.formatMsgNoLookups=true” to disable JNDI lookups when logging. If your software runs on Tomcat, you can alternatively set the option in CATALINA_OPTS. Your software vendor may have further guidance on how to set this option. See [2] for a volunteer maintained list of advisories from popular vendors.
2. If your software uses Log4j >= 2.0 and < 2.10, do either:
   
   1. Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at [2].
   2. Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.
3. Apply egress filtering via a network or host firewall to prevent your server from connecting out to untrusted networks or hosts. Only allow outbound connections to your operating system vendor, your software vendors, and any systems to which you have a business need to integrate. If in doubt, start with restricting access to campus networks only and then add and subtract specific trusted networks and hosts based on vendor and integration partner recommendations as needed. The network IP ranges for the Pittsburgh campus are:
   - 128.2.0.0/16<http://128.2.0.0/16>
   - 128.237.0.0/16<http://128.237.0.0/16>
   - 172.16.0.0/12<http://172.16.0.0/12>

If a patch is available for your Java based software, test and patch as soon as possible.

1. See a volunteer-maintained list of advisories from popular vendors.
2. Consider egress filtering as a best practice to mitigate similar issues in the future.

If you developed your own application:

Apply the mitigations above.

Plan to upgrade to Log4j 2.15.0 or higher in the future iterations of your software development life cycle. The latest version can be found on the Log4j download page.

We will update this alert with any new relevant information or link to CMU ISO or Computing Services if appropriate.

ADDITIONAL INFORMATION:

https://nvd.nist.gov/vuln/detail/CVE-2021-44228 
https://www.lunasec.io/docs/blog/log4j-zero-day/ 
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation 
https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell