The Apache Software Foundation has updated their guidance on fully mitigating the log4j vulnerability and now recommends 2.17.0 as their most secure release. Please review their latest security information at for more information.

Please be advised that multiple critical severity remote code execution vulnerabilities (CVE-2021-44228, CVE-2021-45046) have been discovered in Apache Log4j2 <= 2.14.1, a Java-based logging tool. A new high severity vulnerability (CVE-2021-45105) which could lead to a denial-of-service attack has also been disclosed which affects Apache Log4j2 <= 2.16.0.

What is Log4j?

Log4j is a very popular logging library that is embedded into many applications and services. If you believe you may be running log4j in an embedded application and cannot simply update log4j on its own, we recommend escalating a support request to the vendor for recommendations. It is expected that the number of products potentially impacted by this vulnerability may continue to grow as research continues.

EXAMPLES OF POTENTIALLY IMPACTED WEBSITES, APPLICATIONS, OR DEVICES:

This is not an exhaustive list but gives insight into how wide-ranging this vulnerability is.

• Atlassian - Confluence Server and Data Center

• Amazon Web Services

• CISCO

• Commvault

• Fortinet

• Oracle

• Red Hat

• VMWare

How big of a deal is this vulnerability?

Unauthenticated remote code execution (RCE) is among the worst types of vulnerability exploits as it can easily allow attackers to establish a foothold, take control of a system, and then deploy dangerous malware such as ransomware.

Publicly available exploit code significantly increases the risk of attack, and the security community is actively observing attacks ongoing in the wild.

The Office of the Chief Information Security Officer (OCISO) strongly urges all campus operators who may be leveraging the products that may be impacted by CVE-2021-44228 to take immediate action to patch and/or apply mitigation that will reduce exposure to this vulnerability.

The Apache Software Foundation has released log4j 2.17.0 to patch these vulnerabilities, and for those areas that cannot immediately patch, has also released recommended mitigation which can be reviewed at https://logging.apache.org/log4j/2.x/security.html

Additional information regarding the Log4Shell exploit can be reviewed at the links below:

https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/

https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce

What can I do?

Vendors are rolling out patches/updates as fast as they can. Make sure your internet-connected devices, apps, and software are patched and up to date.

Before leaving campus for the holiday break, power down or remove from the network any servers or devices that will not be in use, especially if you’re not sure if they are affected. 

If you support Campus systems, review your systems now and patch or implement vendor mitigations immediately. If you cannot implement mitigations or install vendor patches, please contact us immediately.

Mitigations

• Java 8 (or later) users should upgrade to release 2.17.0
• Jave 7 users should upgrade to release 2.12.2
• Otherwise, in any release other than < 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that mitigation strategies that were previously recommended by the community and shared on this page (prior to 12/17), including the log4j2.formatMsgNoLookups value set to True, is now being viewed as insufficient to completely mitigate against these vulnerabilities. If you are using third-party software with log4j embedded, please continue to consult the vendor's latest knowledge base articles for recommended mitigation. Removing the JndiLookup class from a third-party application may affect the functionality of the product.

If you are unable to quickly mitigate this vulnerability on a P3 or P4 system, please open a ticket with OCISO by emailing infosecoffice@ucr.edu

If you administer a publicly accessible P3 or P4 system that is vulnerable, after mitigation, examine your access and application logs for occurrences of "${jndi:" . 

If any logs are found, please open a ticket with ISO by emailing infosecoffice@ucr.edu