Unauthenticated RCE in H2 Database Console is similar to Log4Shell

Researchers disclosed a critical RCE flaw in the H2 open-source Java SQL database which is similar to the Log4J vulnerability. Jfrog researchers discovered a critical vulnerability in the H2 open-source Java SQL database related to the Log4Shell Log4J vulnerability. The flaw, tracked as CVE-2021-42392, could allow attackers to execute remote code on vulnerable systems, the […]

January 8, 2022

Researchers disclosed a critical RCE flaw in the H2 open-source Java SQL database which is similar to the Log4J vulnerability.

Jfrog researchers discovered a critical vulnerability in the H2 open-source Java SQL database related to the Log4Shell Log4J vulnerability. The flaw, tracked as CVE-2021-42392, could allow attackers to execute remote code on vulnerable systems, the good news is that unlike the Log4J issue it should not be as widespread.

According to the experts, this vulnerability has the same root cause as the Log4Shell vulnerability in Log4j (JNDI remote class loading). H2 is a popular open-source Java SQL database that offers a lightweight in-memory solution that doesn’t require data to be stored on disk. It is used by various projects from web platforms like Spring Boot to IoT platforms like ThingWorks. The com.h2database:h2 package is part of the top 50 most popular Maven packages, it has 7000 artifact dependencies.”

“Although this is a critical issue with a similar root cause,”reads the post published by JFrog. CVE-2021-42392 should not be as widespread as Log4Shell (CVE-2021-44228) due to the following factors:

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.
On vanilla distributions of the H2 database, by default the H2 console only listens to localhost connections – making the default setting safe. This is unlike Log4Shell which was exploitable in the default configuration of Log4j. However – it’s worth noting the H2 console can easily be changed to listen to remote connections as well.
Many vendors may be running the H2 database, but not running the H2 console. Although 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.“

The H2 flaw allows several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function. This allows for remote codebase loading, also known as Java code injection or remote code execution.

“Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters,” continues the post.“If the driver’s class is assignable to the javax.naming.Context class, the method instantiates an object from it and calls its lookup method.”

Experts warn that the most severe attack vector of this vulnerability is through the H2 web based console. which is embedded in H2 databaseand is available by default on http://localhost:8082 when running the H2 package JAR.

“Access to the console is protected by a login form, which allows passing the “driver” and “url” fields to the corresponding fields of JdbcUtils.getConnection. This leads to unauthenticated RCE, since the username and password are not validated before performing the lookup with the potentially malicious URL.” statethe experts.

Administrators running an H2 console that is exposed to their LAN or WAN are exposed remote code execution attacks and are recommended to update their H2 database installs to version 2.0.206 immediately. Experts also pointed out that many developer tools are relying on the H2 database and specifically exposing the H2 console.