We hope that many H2-dependent developer tools will also be safer after this fix is applied. The recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories, emphasizes the importance of developer tools being made secure for all reasonable use cases. We have also observed that many developer tools are relying on the H2 database and specifically exposing the H2 console (some examples are included later in the blog post).
H2 database update#
That being said, if you are running an H2 console which is exposed to your LAN (or worse, WAN) this issue is extremely critical (unauthenticated remote code execution) and you should update your H2 database to version 2.0.206 immediately. 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. Many vendors may be running the H2 database, but not running the H2 console.However – it’s worth noting the H2 console can easily be changed to listen to remote connections as well. This is unlike Log4Shell which was exploitable in the default configuration of Log4j. On vanilla distributions of the H2 database, by default the H2 console only listens to localhost connections – making the default setting safe.This is less severe compared to Log4Shell since the vulnerable servers should be easier to find. This means that typically the server that processes the initial request (the H2 console) will be the server that gets impacted with RCE. Unlike Log4Shell, this vulnerability has a “direct” scope of impact.The com.h2database:h2 package is part of the top 50 most popular Maven packages, with almost 7000 artifact dependencies.ĭue to the current sensitivities around anything (Java) JNDI-related, we want to clarify a few of the conditions and configurations that must be present in order to be at risk before getting into the technical details of our H2 vulnerability findings.Īlthough this is a critical issue with a similar root cause, CVE-2021-42392 should not be as widespread as Log4Shell (CVE-2021-44228) due to the following factors: This makes it a popular data storage solution for various projects from web platforms like Spring Boot to IoT platforms like ThingWorks.
H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading).
Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. Update 07/01/22 – Added credit to researcher for similar independent previous findings in Acknowledgements section A short preamble
0 kommentar(er)
