CVE-2022-41853

Overview

HSQLDB (HyperSQL Database) is an open source relational database written in Java. It runs embedded inside a Java application or as a standalone server, keeps tables in memory or on disk, and implements much of the SQL standard through a JDBC driver. Its small footprint made it a common embedded and test database, and Spring Boot manages its version for applications that use it.

A remote code execution vulnerability (CVE-2022-41853) has been identified in HSQLDB, which allows attackers who can influence the SQL an application runs to call any public static Java method on the application's classpath.

Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data.

This issue affects all versions of HSQLDB before 2.7.1.

Details

Module Info

• Product: HSQLDB
• Affected packages: org.hsqldb:hsqldb
• Affected versions: <2.7.1
• GitHub repository: https://sourceforge.net/projects/hsqldb/
• Published packages: https://central.sonatype.com/artifact/org.hsqldb/hsqldb
• Package manager: Maven
• Fixed in:
• OSS HSQLDB 2.7.1
• NES for HSQLDB v2.5.4

Vulnerability Info

This Critical-severity vulnerability is found in the org.hsqldb:hsqldb package in all versions of HSQLDB before 2.7.1.

HSQLDB lets SQL call static Java methods as functions. The hsqldb.method_class_names system property is meant to limit which methods SQL can reach, but the check fails open. HsqlDatabaseProperties builds the allowlist only when the property is set, and supportsJavaMethod treats a missing allowlist as permission for everything:

private static HashSet accessibleJavaMethodNames;

static {
    String prop = System.getProperty(hsqldb_method_class_names);

    if (prop != null) {
        accessibleJavaMethodNames = new HashSet();
        // split prop on ';' and add each name
    }
}

public static boolean supportsJavaMethod(String name) {

    if (accessibleJavaMethodNames == null) {
        return true;
    }
    ...

The property is unset by default, so every public static method on the classpath is callable. Routine.getMethods consults supportsJavaMethod on every route to a Java method: a quoted method name used directly in a query, which needs no DDL (VALUES("java.lang.System.setProperty"('k', 'v'))); a CREATE FUNCTION or CREATE PROCEDURE with LANGUAGE JAVA; and the legacy CREATE ALIAS.

Exploitation needs attacker-influenced text to reach SQL on a connection whose user may execute routines, for example a value concatenated into a Statement, or an exposed query console. The default SA account, which embedded applications commonly use, has that right; a user created with CREATE USER and no extra grants is refused by privilege checking first. From there, one statement can call any public static method in the JDK or in a library on the classpath, which is enough to run arbitrary code.

Steps to Reproduce

Put org.hsqldb:hsqldb:2.5.2 on the classpath, leave hsqldb.method_class_names unset, and run:

try (Connection c = DriverManager.getConnection("jdbc:hsqldb:mem:poc", "SA", "");
     Statement st = c.createStatement()) {
    st.executeQuery("VALUES(\"java.lang.System.setProperty\"('pwned', 'yes'))");
    System.out.println(System.getProperty("pwned"));
}

The program prints yes: one SQL statement called java.lang.System.setProperty inside the JVM.

Mitigation

HSQLDB 2.5.x is End-of-Life: HyperSQL publishes fixes only on its newest release line, and no 2.5.x release has shipped since 2.5.2 in April 2021.

On an affected version, setting the hsqldb.method_class_names system property turns the allowlist on, even with an empty value. Only java.lang.Math methods and the names listed stay callable. Set it on the java command line, because HSQLDB reads it once when its classes load:

java -Dhsqldb.method_class_names="com.example.DateUtils.*" ...

Users of the affected components should apply one of the following mitigations:

• Upgrade to HSQLDB 2.7.1 or later. Java 8 applications can use the jdk8 classifier jar published with each 2.7.x release.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.