H2 Database Console Log4j-ish Attack Vector Discovered

A vulnerability with the same root cause as the notorious log4j discovered flaws has been patched in the console of the hugely popular Java SQL database, H2 Database Engine.

As with the recent ‘Log4Shell’ exploits, unauthenticated attackers can achieve remote code execution (RCE) because the console accepts arbitrary Java Naming and Directory Interface (JNDI) lookup URLs.

The issue, tracked as CVE-2021-42392, is the ” first critical issue published since Log4Shell, on a component other than Log4j, that exploits the same root cause of the Log4Shell vulnerability, namely JNDI remote class loading,” JFrog researchers Andrey Polkovnychenko and Shachar Menashe said.

H2 is an open-source relational database management system written in Java that can be embedded within applications or run in a client-server mode. According to the Maven Repository, the H2 database engine is used by 6,807 artifacts.

JNDI, short for Java Naming and Directory Interface, refers to an API that provides naming and directory functionality for Java applications, which can use the API in conjunction with LDAP to locate a specific resource that it might need.

In the case of Log4Shell, this feature enables runtime lookups to servers, both inside and outside the network, which, in turn, can be weaponized to allow unauthenticated remote code execution and implant malware on the server by crafting a malicious JNDI lookup as input to any Java application that uses vulnerable versions of the Log4j library to log it.

“Similar to the Log4Shell vulnerability uncovered in early December, attacker-controlled URLs that propagate into JNDI lookups can allow unauthenticated remote code execution, giving attackers sole control over the operation of another person or organization’s systems,” Menashe, senior director of JFrog security research, explained.

The flaw affects H2 database versions 1.1.100 to 2.0.204 and has been addressed in version 2.0.206 shipped on January 5, 2022.

“The H2 database is used by many third-party frameworks, including Spring Boot, Play Framework and JHipster,” Menashe added. “While this vulnerability is not as widespread as Log4Shell, it can still have a dramatic impact on developers and production systems if not addressed accordingly.”