CVE-2024-42198: pgjdbc SCRAM Auth CPU Exhaustion DoS and Fix

Vulnerability Summary: Unrestricted SCRAM Authentication Iterations in pgjdbc Leading to CPU Exhaustion Vulnerability Overview CVE-2024-42198 Vulnerability Type: Client-side Denial of Service (DoS) Affected Component: (Maven) Affected Versions: > 42.2.0 Fixed Version: 42.7.11 CVSS Score: 7.5 (High) Description: A vulnerability exists in pgjdbc during the SCRAM-SHA-256 authentication process. A malicious server can instruct the driver to perform SCRAM authentication with an excessively high number of iterations. Due to the lack of an upper limit, the client spends a significant amount of CPU time on authentication, leading to CPU exhaustion and potentially hanging the connection pool. Impact Scope Availability: Affected. Repeated or concurrent connection attempts will exhaust client CPU resources and hang the connection pool. Other Impacts: Does not provide authentication bypass, privilege escalation, or direct password leakage. Trigger Conditions: 1. The connection uses SCRAM-SHA-256 authentication. 2. The client connects to a malicious, compromised, or attacker-controlled PostgreSQL endpoint. 3. The endpoint sends a very large SCRAM PBKDF2 iteration count in the . High-Risk Scenarios: Applications allow users/tenants to provide their own database connection details (e.g., BI, ETL platforms). Applications accept connection strings, hostnames, or JDBC URLs from user input. Applications are configured to connect to untrusted PostgreSQL servers. Connections are made through untrusted proxies, tunnels, or connection pool services. Attackers redirect clients to forged PostgreSQL endpoints via DNS spoofing, service discovery, or Kubernetes service redirection. Active network attackers can impersonate servers (e.g., using lower than , or trusting externally signed CAs). Applications use connection retries, a large number of parallel connection attempts, or have configured. Remediation Patch Introduces a new connection property , with a default value of 100K. The client now rejects SCRAM iteration counts advertised in server messages that exceed the configured limit before starting the PBKDF2 calculation. Workarounds Before deploying the patched version, the following measures can be taken to reduce exposure: 1. Connect only to trusted PostgreSQL servers: Ensure their identity is verified. Connect only to trusted PostgreSQL servers, and use TLS with and trusted CA verification to authenticate identity. TLS that relies solely on certificate and hostname verification is insufficient to prevent active network attackers from impersonating servers. 2. Do not rely on as a complete mitigation: On affected versions, only stops the waiting caller, but the worker thread continues to consume CPU. 3. Avoid using SCRAM on untrusted or interceptable connection paths: For these paths, use authentication methods that do not allow the server to select the SCRAM PBKDF2 iteration count. 4. Reduce blast radius at the operational level: Limit parallel connection attempts, add retry backoff, isolate connection establishment in separate workers or processes, and apply CPU or container limits where appropriate. 5. Keep SCRAM iteration counts at normal levels on trusted servers under your control: This does not defend against attacker-controlled servers but avoids unnecessary client-side costs when communicating with legitimate servers.

Goal Reached Thanks to every supporter — we hit 100%!

CVE-2024-42198: pgjdbc SCRAM Auth CPU Exhaustion DoS and Fix

More from this source