In June 2024, a new security vulnerability was disclosed in the Amazon Redshift JDBC Driver, tracked as CVE-2024-32888. This vulnerability allows SQL injection attacks when a specific (non-default) connection property called preferQueryMode=simple is manually set. In this long read, we'll break down exactly how the vulnerability happens, show you exploit code, link to technical resources, and discuss mitigation steps. All technical jargon is explained so that even folks without deep security backgrounds can follow along.

What is the Amazon Redshift JDBC Driver?

Amazon’s Redshift JDBC Driver lets Java applications connect securely to Amazon Redshift databases. Most users run it with its default settings, which are safe. The driver supports various query modes to talk to Redshift, but unless you’re modifying internal settings, you’re likely using the default, which is immune to this bug.

Understanding the Risk: preferQueryMode=simple

The root cause of CVE-2024-32888 is the unsupported preferQueryMode property. If set to simple, SQL injection becomes possible in apps that build SQL queries with unsafe string concatenation, especially when _negating_ a parameter value (using !param or similar logic).

You set preferQueryMode=simple manually in your JDBC connection string.

2. Your application has some SQL that negates a parameter value and does not properly parameterize user input.

If you don’t change any advanced driver settings, you’re fine!

Suppose you have an application that does something like this in Java

// Vulnerable Java code snippet (for educational use)

// Connect using preferQueryMode=simple
String url = "jdbc:redshift://hostname:5439/db?preferQueryMode=simple";
Connection conn = DriverManager.getConnection(url, user, pass);

String userInput = request.getParameter("userid");
// Negation in SQL, potentially vulnerable if not parameterized
String query = "SELECT * FROM users WHERE NOT id=" + userInput;

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(query);

If a malicious user sends userInput as 5 OR 1=1--, the resulting SQL is

SELECT * FROM users WHERE NOT id=5 OR 1=1--

This returns ALL users because the injected OR 1=1 logic always evaluates true.

Normally, if you use prepared statements, the driver will safely parameterize inputs

// Safe version
String query = "SELECT * FROM users WHERE NOT id=?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, Integer.parseInt(userInput));
ResultSet rs = stmt.executeQuery();

But with preferQueryMode=simple, the driver skips parameterization, and *directly* concatenates values into SQL, making injection attacks possible if your code isn’t using prepared statements.

1. Fixed in Version 2.1..28

Amazon shipped a patch in driver version 2.1..28 that fixes this issue. If you use this or newer, you are not vulnerable.

2. Avoid Using preferQueryMode=simple

Simply do not use this property. It was never an intended option for Redshift JDBC users.

3. Always Parameterize Queries

Even if running older versions, *never* construct SQL queries with user input using string concatenation. Always use PreparedStatement or an equivalent.

References

- CVE-2024-32888 on NVD
- Amazon Redshift JDBC Driver GitHub
- 2.1..28 Release Notes
- PostgreSQL JDBC Documentation
- OWASP SQL Injection Guide

Final Thoughts

CVE-2024-32888 is a cautionary tale about using settings or features that aren't officially supported or documented. Most Redshift JDBC driver users are NOT affected, but if you or your team have copied over old PostgreSQL settings or experimented with undocumented properties, take a moment to review your JDBC URLs and update to the latest driver version.

Bottom line:
Don’t use preferQueryMode=simple. Always validate and parameterize user input. And keep your dependencies up-to-date!


*For questions or technical help, visit the Amazon Redshift JDBC Driver GitHub repo.*

Timeline

Published on: 05/15/2024 03:15:12 UTC
Last modified on: 06/04/2024 17:49:45 UTC