The PostgreSQL JDBC Driver (pgjdbc) is a widely used open source library that enables Java applications to interact with PostgreSQL databases. In 2022, a vulnerability was discovered affecting how the driver handles large InputStreams used in certain prepared statements. This vulnerability—CVE-2022-41946—could let other users on the same machine read sensitive data from temporary files. Let’s break down how this issue happens, how you can exploit it, and—most importantly—how to fix or mitigate it if you’re at risk.
What’s the Core Problem?
Many applications use prepared statements to securely interact with databases. It’s common to send large binary or text values to PostgreSQL using methods like PreparedStatement.setText(int, InputStream) or PreparedStatement.setBytea(int, InputStream). If the InputStream is larger than 2KB, pgjdbc (in affected versions) writes this data to a temporary file—usually in a "system temp directory" (like /tmp on Unix-like systems).
Here’s the catch: These temporary files are created world-readable by default! On typical Unix-like systems, the temp directory is shared by all users. Any local user—or malware running as a user on the system—can peek into the temp files your Java app creates, and read things they shouldn’t see. This is a classic information disclosure problem.
MacOS: Not affected due to how temp files are managed there.
Reference: pgjdbc security advisory
Suppose your app writes confidential user data to the database
try (PreparedStatement ps = connection.prepareStatement(
"INSERT INTO users (username, profile_pic) VALUES (?, ?)")) {
ps.setString(1, "alice");
// The file is bigger than 2KB
InputStream pic = new FileInputStream("/home/alice/photos/private_pic.jpg");
ps.setBinaryStream(2, pic);
ps.executeUpdate();
}
What happens under the hood:
If private_pic.jpg > 2KB, pgjdbc writes it to something like /tmp/pgjdbcXXXX.tmp temporarily. On Unix, this file is world-readable by default.
2. An Attacker Grabs the Data
Any local user on the machine can snoop on /tmp/pgjdbcXXXX.tmp files—just by listing files and reading new ones as they appear:
# Attacker process on the same host
ls -ltr /tmp/pgjdbc*
cat /tmp/pgjdbcXXXX.tmp # Replace with the actual temp filename
# Now attacker sees Alice's private_pic.jpg before the app deletes the file!
There’s no way for the attacker to overwrite or control what data lands in these files, but they can read sensitive stuff.
Why This Matters
- Multi-user, shared servers: Apps running on shared servers (think university servers, old VMs, or community development environments) could leak critical application or user data to other users with simple shell commands.
- Sensitive Data: Anything sent via streams—images, documents, even moderately sized text blobs—may be exposed before deletion.
How the Vulnerability Was Fixed
In version 4.5., pgjdbc now creates its temporary files using Java's file APIs that can mark the file as private to the Java process (mode 060). This stops other users from reading the temp files.
Important note: Java 1.7+ introduced better file permissions APIs, so the patch only works for recent Java platforms. If you’re still on Java 1.6 or below, you can’t upgrade to a secure version.
Reference: CVE-2022-41946 NVD entry
2. Mitigation for Old Java (1.6 and earlier)
Set the java.io.tmpdir property to a private directory owned and readable only by your app’s user. For example:
# Before starting your Java app
mkdir -m 700 /home/myappuser/tmp
export JAVA_OPTS="$JAVA_OPTS -Djava.io.tmpdir=/home/myappuser/tmp"
In Java
System.setProperty("java.io.tmpdir", "/home/myappuser/tmp");
Make sure:
Conclusion
CVE-2022-41946 shows how even well-reviewed open source libraries can make dangerous assumptions about system defaults. If your Java app consumes large streams through pgjdbc—especially on shared or sensitive infrastructure—check your pgjdbc version and Java runtime, and patch ASAP.
Useful Links:
- CVE-2022-41946 on GitHub Security Advisory
- National Vulnerability Database Entry
- pgjdbc Release Notes
Stay safe, audit your dependencies, and always keep an eye on where your temporary files go!
Timeline
Published on: 11/23/2022 20:15:00 UTC
Last modified on: 07/06/2023 13:37:00 UTC