The remotely exploitable flaw in Log4j – the widely deployed Java error logging library — is being attacked by multiple actors and likely will remain so for many more months as open-source projects, product vendors, and end-user organisations patch affected systems.
Google is now adding OSS-Fuzz to the pool of answers to the internet-wide Log4j flaw, also known as Log4Shell. The bug is tracked as CVE 2021-44228 and was partially fixed in Apache Foundation’s release of Log4j version 2.15.0 last week.
OSS-Fuzz is Google’s free service for fuzzing open-source software projects and is currently used by over 500 critical projects. Fuzzing involves throwing random code at software to produce an error, like a crash, and uncover potential security flaws.
LOG4J flaw coverage — What you need to know now:
To seek out Log4Shell weaknesses in newly built open-source software, Google is partnering with security firm Code Intelligence to provide continuous fuzzing for Log4j.
Code Intelligence makes Jazzer, an open-source fuzzing engine that’s now part of OSS-Fuzz, and has been modified to identify Log4j vulnerabilities in code in development. Google awarded Code Intelligence $25,000 for its work on the Log4j fuzzing.
“Since Jazzer is part of OSS-Fuzz, all integrated open-source projects written in Java and other JVM-based languages are now continuously searched for similar vulnerabilities,” Code Intelligence notes in a press release.
Jazzer is also capable of detecting remote JNDI lookups — a strong sign that potential attackers are scanning a network for the flaw.
JNDI (Java Naming and Directory Interface) is an interface for connecting to directories in Lightweight Directory Access Protocol (LDAP) servers, and the flaw in Log4j is found in its implementation of JNDI.
As Cisco’s Talos researchers explain, the flaw allows a remote attacker to use a simple LDAP request to trigger the vulnerability in pre-2.15 versions of Log4j, then retrieve a payload from a remote server and execute it locally on a vulnerable device.
Apache Foundation this week released Log4j version 2.16.0 to fix a second related flaw stemming from JNDI that’s being tracked as CVE 2021-45046. That flaw allowed an attacker to craft data patterns in a JNDI message lookup and cripple a machine with a denial of service (DoS).
Log4j 2.16.0 disables access to JNDI by default and limits the default protocols to Java, LDAP and LDAPS. Disabling JNDI was previously a manual step to mitigate attacks against the original flaw.
Most efforts are now focussed on vendors updating Log4j in their products and end-user organisations applying updates as they become available. For example, the US Cybersecurity and Infrastructure Security Agency (CISA) has given federal agencies until 24 December to identify all applications affected by Log4Shell. Cisco, VMware, IBM and Oracle are busy developing patches for their affected products.
LOG4J flaw coverage — How to keep your company safe:
Google’s OSS-Fuzz tackles Log4j from another angle, aiming to prevent developers from accidentally inserting the flaw in new software projects that may eventually be deployed in production environments.
“Vulnerabilities like Log4Shell are an eye-opener for the industry in terms of new attack vectors. With OSS-Fuzz and Jazzer, we can now detect this class of vulnerability so that they can be fixed before they become a problem in production code,” says Jonathan Metzman from the Google Open Source Security Team.
