CVE-2024-27304

Executive Summary

CVE-2024-27304 is a critical SQL injection vulnerability in the pgx PostgreSQL driver for Go. The flaw arises from an integer overflow when a single query or bind message exceeds 4 GB in size. An attacker can exploit this to cause the driver to split the oversized message into multiple smaller messages, effectively injecting arbitrary SQL commands. With a CVSS score of 9.8, this vulnerability allows unauthenticated remote attackers to execute arbitrary SQL, leading to complete compromise of confidentiality, integrity, and availability of the database.

Supply Chain & Package Security

This vulnerability affects the Go package pgx, a widely used PostgreSQL driver. Organizations using pgx in their Go applications must update to patched versions immediately. The supply chain risk is high because the vulnerability is in a core database driver, potentially impacting any application that uses it.

CVSS Breakdown & Threat Level

• CVSS Score: 9.8 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: High

The threat level is critical due to the low attack complexity and no required privileges or user interaction. An attacker can exploit this remotely to gain full control over the database.

Deep Dive & Mechanics

The vulnerability is in the message size calculation within pgx. When constructing a query or bind message, the driver calculates the total size. If the size exceeds 4 GB, an integer overflow occurs, wrapping the value to a smaller number. This causes the driver to send the oversized payload as multiple smaller messages, each interpreted as a separate query. An attacker can craft a payload that, after the overflow, results in a valid SQL injection.

The root cause is the use of a 32-bit integer for message size, which overflows at 4 GB. The fix in v4.18.2 and v5.5.4 uses a 64-bit integer or adds proper bounds checking.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

func (b *writeBuf) startMsg(msgType byte) {
    b.startIdx = len(b.buf)
    b.buf = append(b.buf, msgType, 0, 0, 0, 0) // 4 bytes for size
}

func (b *writeBuf) finishMsg() {
    size := len(b.buf) - b.startIdx - 1
    binary.BigEndian.PutUint32(b.buf[b.startIdx+1:], uint32(size)) // overflow here
}

Patched Code (simplified):

func (b *writeBuf) finishMsg() {
    size := len(b.buf) - b.startIdx - 1
    if size > math.MaxInt32 {
        panic("message too large")
    }
    binary.BigEndian.PutUint32(b.buf[b.startIdx+1:], uint32(size))
}

The patched version adds a check to ensure the size does not exceed the maximum 32-bit integer, preventing the overflow.

Exploitation & Lab Setup

Red Team

1. Setup: Deploy a vulnerable Go application using pgx < 4.18.2 or < 5.5.4.
2. Craft Payload: Create a query that, when combined with padding, exceeds 4 GB. The payload should contain SQL injection after the overflow.
3. Send Request: Use a tool like curl or a custom script to send the oversized query.
4. Exploit: The overflow causes the driver to split the message, executing the injected SQL.

Example Payload (conceptual):

import socket

payload = b"SELECT * FROM users WHERE id = 1; " + b"A" * (4 * 1024 * 1024 * 1024) + b" UNION SELECT * FROM secrets;"
# Send to vulnerable server

Blue Team

1. Monitor Network Traffic: Look for unusually large PostgreSQL messages (> 4 GB).
2. Detect Anomalies: Use network monitoring tools to flag oversized packets.
3. Log Analysis: Check database logs for unexpected query patterns or errors related to message size.
4. Honeypot: Deploy a honeypot with a vulnerable pgx version to capture exploitation attempts.

Indicators of Compromise (IOCs)

• Network: PostgreSQL messages exceeding 4 GB in size.
• Logs: Database errors related to message size or unexpected query splitting.
• System: Unusual database queries containing large padding or SQL injection patterns.
• File: Modified Go binaries or libraries with patched pgx versions.

Detection Engineering

YARA Rule

rule CVE_2024_27304_pgx_overflow {
    meta:
        description = "Detects pgx versions vulnerable to CVE-2024-27304"
        author = "Valters IT"
        date = "2024-01-01"
    strings:
        $vuln_func = "finishMsg" ascii wide nocase
        $vuln_size = "PutUint32" ascii wide nocase
    condition:
        $vuln_func and $vuln_size
}

Sigma Rule

title: CVE-2024-27304 pgx SQL Injection via Integer Overflow
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects oversized PostgreSQL messages indicating exploitation attempt
logsource:
    category: network
    product: postgresql
detection:
    selection:
        size: > 4294967295
    condition: selection
falsepositives:
    - Legitimate large data transfers
level: critical

Suricata Rule

alert tcp any any -> any 5432 (msg:"CVE-2024-27304 pgx SQL Injection Attempt"; flow:to_server; content:"|00 00 00 00|"; depth:4; byte_test:4,>,4294967295,0,relative; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade pgx to v4.18.2 or v5.5.4.
2. Workaround: Reject user input that could cause a single query or bind message to exceed 4 GB.
3. Network: Implement network segmentation to limit database exposure.
4. Monitoring: Deploy detection rules to identify exploitation attempts.
5. Patch Management: Ensure all Go applications using pgx are updated.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert