New Log4Shell-like vulnerability impacts H2 Java SQL database

Researchers have warned of a new, critical Java flaw impacting the console of the popular H2 Java SQL database with the same root cause as the Log4Shell vulnerability in Apache Log4j. According to JFrog, the issue carries a critical risk of unauthenticated remote code execution (RCE) for certain organisations who should update their H2 databases immediately.

H2 vulnerability root cause similar to Log4Shell, less exploitation scope

Like Log4Shell, the flaw (CVE-2021-42392) relates to Java Naming and Directory Interface (JNDI) remote class loading. An attacker could trigger RCE if they are able to insert a malicious URL into a JNDI lookup, JFrog researchers explained in a blog post.

“In a nutshell, the root cause is similar to Log4Shell – several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function, which allows for remote codebase loading (AKA Java code injection AKA remote code execution).” 

Any organisation running an H2 console which is exposed to its LAN or WAN is at critical risk, while the threat posed to H2-dependent developer tools is also significant, JFrog said.

However, CVE-2021-42392, which is currently awaiting National Vulnerability Database analysis, differs significantly from the Log4j vulnerability in its exploitation scope, the researchers added. 

“Unlike Log4Shell, this vulnerability has a ‘direct’ scope of impact. This means that typically the server that processes the initial request (the H2 console) will be the server that gets impacted with RCE. This is less severe compared to Log4Shell since the vulnerable servers should be easier to find.”

Furthermore, on vanilla distributions of the H2 database, the H2 console only listens to localhost connections by default – making the default setting safe. “This is unlike Log4Shell, which was exploitable in the default configuration of Log4j.” 

Many vendors may also be running the H2 database, but not running the H2 console itself, and while there are other vectors to exploit this issue other than the console, these other vectors are context-dependent and less likely to be exposed to remote attackers, JFrog said.

To check whether an organisation is vulnerable to CVE-2021-42392, network administrators can scan their local subnets for open instances of the H2 console with nmap.

How to mitigate the RCE threat from CVE-2021-42392

Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, says the new vulnerability will likely present security teams with similar headaches as the Log4Shell disclosure. It may particularly affect Apache Maven packages, a software project management and comprehension tool. 

“As with Log4Shell, one of the major hurdles will be rushing to identify susceptible systems and remediate them before attackers can exploit them in live attacks,” he tells CSO.

To address the issue and reduce the risk of falling victim to RCE, all users of the H2 database should upgrade to version 2.0.206, which limits JNDI URLs to use the (local) Java protocol only, the JFrog researchers said. This should be done even if they are not directly using the H2 console, they added. “This is due to the fact that other attack vectors exist, and their exploitability may be difficult to ascertain.”

If updating H2 is not possible, newer versions of Java that contain the trustURLCodebase mitigation can prevent remote codebases from being loaded naively via JNDI. This mitigation is not bulletproof, however, and is enabled by default on the following or later versions of Java: 6u211, 7u201, 8u191, and 11.0.1.

In addition, “when the H2 console Servlet is deployed on a web server (not using the standalone H2 web server), a security constraint can be added that will allow only specific users access to the console page,” JFrog’s posting read.