CVE-2025-64335: Oisf Suricata NULL Dereference Vulnerability

CVE-2025-64335 Overview

CVE-2025-64335 is a Null Pointer Dereference vulnerability affecting Suricata, the open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine developed by the Open Information Security Foundation (OISF) and the Suricata community. The vulnerability exists in versions 8.0.0 through 8.0.1, where a NULL dereference can occur when the entropy keyword is used in conjunction with base64_data within detection rules.

Critical Impact

Attackers can remotely trigger a denial of service condition by exploiting the NULL dereference, potentially causing Suricata to crash and leaving network traffic unmonitored.

Affected Products

• OISF Suricata versions 8.0.0 to 8.0.1

Discovery Timeline

• 2025-11-26 - CVE-2025-64335 published to NVD
• 2025-12-12 - Last updated in NVD database

Technical Details for CVE-2025-64335

Vulnerability Analysis

This vulnerability is a classic Null Pointer Dereference (CWE-476) that occurs within Suricata's rule parsing and detection engine. The issue manifests when processing detection rules that combine the entropy keyword with base64_data. When this specific combination is encountered, the DetectEngineBufferTypeGetNameById() function can return a NULL pointer that is subsequently used without validation, leading to a crash.

The vulnerability is particularly concerning for organizations relying on Suricata for network security monitoring, as it can be triggered remotely through network traffic that causes evaluation of affected rules. This creates a denial of service condition where the IDS/IPS engine becomes unavailable, potentially leaving the network unprotected during the attack window.

Root Cause

The root cause lies in the detect-entropy.c source file, specifically in how buffer type names are resolved when the entropy keyword is used with base64_data. The code path for DETECT_SM_LIST_BASE64_DATA was not properly handled, causing DetectEngineBufferTypeGetNameById() to return NULL. The fix implements explicit handling for the base64_data case and adds a fallback mechanism for unknown buffer types to prevent NULL dereferences.

Attack Vector

The attack vector is network-based with no authentication or user interaction required. An attacker can craft network traffic designed to trigger rules that use the entropy keyword with base64_data, causing the NULL dereference and subsequent crash. This vulnerability affects availability only, with no direct impact on confidentiality or integrity.

// Security patch from src/detect-entropy.c
// Source: https://github.com/OISF/suricata/commit/c935f08cd988600fd0a4f828a585b181dd5de012

             goto error;
 
         sm_list = s->init_data->list;
-        ded->fv_idx = VarNameStoreRegister(
-                DetectEngineBufferTypeGetNameById(de_ctx, sm_list), VAR_TYPE_FLOW_FLOAT);
+        const char *name;
+        if (sm_list == DETECT_SM_LIST_BASE64_DATA) {
+            name = "base64_data";
+        } else {
+            name = DetectEngineBufferTypeGetNameById(de_ctx, sm_list);
+            if (name == NULL) {
+                DEBUG_VALIDATE_BUG_ON(1);
+                name = "unknown";
+            }
+        }
+        ded->fv_idx = VarNameStoreRegister(name, VAR_TYPE_FLOW_FLOAT);
     } else {
         ded->fv_idx = VarNameStoreRegister("content", VAR_TYPE_FLOW_FLOAT);
     }

Source: GitHub Commit

Detection Methods for CVE-2025-64335

Indicators of Compromise

• Unexpected Suricata process crashes or service restarts without clear operational cause
• Segmentation fault entries in Suricata logs referencing detect-entropy.c or entropy-related processing
• Gaps in network monitoring logs indicating periods where Suricata was unavailable
• Core dumps generated by Suricata containing stack traces pointing to entropy keyword handling

Detection Strategies

• Monitor Suricata process health using tools like systemctl status suricata or process monitoring solutions
• Implement automated alerting for Suricata service crashes and automatic restart attempts
• Review Suricata rule files to identify any rules combining entropy with base64_data keywords
• Deploy crash dump analysis to identify exploitation attempts via stack trace patterns

Monitoring Recommendations

• Configure watchdog services to detect and alert on Suricata process failures
• Enable core dump collection for forensic analysis in case of crashes
• Monitor network traffic for patterns that may indicate exploitation attempts
• Set up redundant IDS/IPS instances to maintain coverage during potential service disruptions

How to Mitigate CVE-2025-64335

Immediate Actions Required

• Upgrade Suricata to version 8.0.2 or later immediately
• Review all deployed Suricata rules for combinations of entropy and base64_data keywords
• Implement the workaround by disabling affected rules until patching is complete
• Ensure high availability configurations are in place to minimize impact from potential crashes

Patch Information

OISF has released Suricata version 8.0.2 which addresses this vulnerability. The patch adds explicit handling for base64_data buffer types and implements a fallback mechanism to prevent NULL pointer dereferences. The fix can be reviewed in the GitHub commit c935f08cd988600fd0a4f828a585b181dd5de012. Additional technical details are available in the GitHub Security Advisory.

Workarounds

• Disable or remove rules that use entropy in conjunction with base64_data until upgrading
• Implement rate limiting on traffic that could trigger entropy-based detection rules
• Deploy redundant Suricata instances to maintain monitoring coverage during potential crashes
• Use signature-based detection alternatives that don't rely on the affected keyword combination

# Configuration example - Identify and disable affected rules
# Search for rules using both entropy and base64_data keywords
grep -r "entropy" /etc/suricata/rules/*.rules | grep "base64_data"

# Comment out or disable identified rules until upgrade is complete
# Add # prefix to disable specific rules in your rules files

# Restart Suricata after rule modifications
sudo systemctl restart suricata

# Verify Suricata version after upgrade
suricata --build-info | grep "Suricata version"