As defenders continue the work of remediating the various Log4j vulnerabilities in their environments, researchers are beginning to discover similar flaws related to JNDI remote class loading in other tools. This week, researchers disclosed a JNDI-related vulnerability in the H2 database console that can allow unauthenticated remote code execution.
H2 is an open source database that is used in a wide range of projects and products, including IoT platforms. It is lightweight and doesn’t write data to disk, so it is flexible and researchers at JFrog, a software management platform provider, discovered a JNDI-related vulnerability in many versions of the H2 console. The flaw (CVE-2021-42392) allows an attacker to execute arbitrary code on a vulnerable server by sending a malicious request.
“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),” Andrey Polkovnychenko and Shachar Menashe of JFrog wrote in a post explaining the bug.
“Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters. 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.”
The vulnerability affects versions of the H2 console going back to 2008, from version 1.1.100 to 2.0.204. The H2 maintainers have released an updated version, 2.0.206, that remediates the flaw.
The most likely and problematic attack vector is through the H2 web console, which is included with the database package.
“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,” the JFrog post says.
There are some mitigating factors in this situation, most importantly the fact that the H2 console is only accessible locally by default. Users can change that configuration if they wish, but the default option is local access only.
“H2 Console doesn't accept remote connections by default. If remote access was enabled explicitly and some protection method (such as security constraint) wasn't set, an intruder can load own custom class and execute its code in a process with H2 Console (H2 Server process or a web server with H2 Console servlet),” the H2 advisory says.
The H2 database is included in a huge number of other packages and apps, so the effects of this flaw could be widespread.