Researchers discovered a bug related to the Log4J logging library vulnerability, which in this case opens the door for an adversary to execute remote code on vulnerable systems. However, this flaw does not pose the same risk as the previously identified in Log4Shell, they said.
JFrog security discovered the flaw and rated critical in the context of the H2 Java database console, a popular open-source database, according to a Thursday blog post by researchers.
H2 is attractive to developers for its lightweight in-memory solution–which precludes the requirement for data to be stored on disk—and is used in web platforms such as Spring Boot and IoT platforms such as ThingWorks.
However, the flaw (CVE-2021-42392) is similar to Log4Shell. “[I]t should not be as widespread” due to a few conditions and factors, JFrog researchers Andrey Polkovnychenko and Shachar Menashe wrote in their post.
Log4Shell (CVE-2021-44228) was tied to the Apache Log4j logging library in early December and immediately exploited by attackers. It spawned 60 variants of the original exploit created for the flaw in a 24-hour period as well as a faulty fix that could cause DoS attacks when it was first released.
How is the H2 Bug Similar to Log4J?
The root cause of the H2 flaw is based in JNDI remote class loading, making it similar to Log4Shell in that it 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, researchers said.
“Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters,” they explained in 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.”
Reasons to Be Wary, but Not Panic
However, unlike Log4Shell, the H2 flaw has a “direct” scope of impact, meaning that typically the server that processes the initial request—that is, the H2 console—will feel the direct brunt of the remote code execution (RCE) bug, researchers wrote in a post published Thursday.
“This is less severe compared to Log4Shell since the vulnerable servers should be easier to find,” researchers wrote.
Secondly, by default on vanilla distributions of the H2 database, the H2 console only listens to localhost connections, thus making the default setting safe, they noted.
“This is unlike Log4Shell which was exploitable in the default configuration of Log4j,” researchers wrote. Still, the H2 console can easily be modified to listen to remote connections as well, which would widen the risk, researchers added.
Indeed, this aspect of the execution of the flaw definitely lessens its severity in comparison to the Log4j issue, noted one security professional.
“Log4j was unique in that any number of attack-manipulated strings, from headers to URL paths, could result in exploitation of the victim depending on how the application was set up to utilize logging with Log4j,” Matthew Warner, CTO and co-founder at automated threat detection and response technology provider Blumira, wrote in an email to Threatpost. “In this case, the H2 database console must be purposefully exposed to the internet by changing the configuration.”
Thirdly, while many vendors may be running the H2 database, they may not run the H2 console with it, JFrog researchers said. There are other attack vectors that can exploit the H2 flaw; however, they are “context-dependent and less likely to be exposed to remote attackers,” researchers observed.
Who Is At Risk?
If the H2 flaw doesn’t deserve the same alarm as Log4Shell, why is it worth noting, one may ask. The JFrog team said that it can be extremely critical and allow for unauthenticated RCE to those running an H2 console exposed to a local area network (LAN) or, even worse, a wide area network (WAN). Indeed, attacking the H2 console directly is the most severe attack vector, researchers said.
Blumira’s Warner said that according to open-source intelligence (OSINT), there are likely less than 100 servers on the internet impacted by the H2 flaw, “so only a very limited number of organizations” are directly affected, he said.
“This vulnerability is a good reminder that it is important to ensure that sensitive services are only internally exposed to mitigate potential future risks,” Warner added.
Still, JFrog researchers said that many developer tools rely on the H2 database and specifically expose the H2 console. This is worrying due to the “recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories.”
These attacks emphasize “the importance of developer tools being made secure for all reasonable use cases,” researchers wrote, which is why they hope many H2-dependent tools will be safer after applying their recommended fix.
On that point, the JFrog team recommends that all users of the H2 database to upgrade to version 2.0.206, which fixes CVE-2021-42392 by limiting JNDI URLs to use the local java protocol only, denying any remote LDAP/RMI queries, researchers explained.
“This is similar to the fix applied in Log4j 2.17.0,” they wrote.
Even those not directly using the H2 console should update “due to the fact that other attack vectors exist, and their exploitability may be difficult to ascertain,” researchers added.
Password Reset: On-Demand Event: Fortify 2022 with a password-security strategy built for today’s threats. This Threatpost Security Roundtable, built for infosec professionals, centers on enterprise credential management, the new password basics and mitigating post-credential breaches. Join Darren James, with Specops Software and Roger Grimes, defense evangelist at KnowBe4 and Threatpost host Becky Bracken. Register & stream this FREE session today – sponsored by Specops Software.
