Suricata is a super popular open-source network threat detection tool, used all over the world for detecting intrusion attempts, malware traffic, and more. But if you’re using a version before 6..13, you could be at risk from a sneaky vulnerability known as CVE-2023-35852 that makes it possible for a hacker to exploit a rules file and write files anywhere on your system.

In this article, we’ll break down the details of this bug, show you how it works, and explain what you can do to stay safe. If you're a system administrator, security enthusiast, or just a Suricata user, this long read will help you understand the vulnerability—without complicated jargon.

What is CVE-2023-35852?

CVE-2023-35852 is a directory traversal vulnerability in Suricata before version 6..13. The issue is in the way Suricata handles dataset filenames that come from rules. If an attacker can get Suricata to load a malicious rules file from an untrusted source, they can use a special path in the dataset rule to make Suricata write files outside of its intended area—maybe even overwriting or creating files elsewhere in your system.

The dataset filename is specified directly inside the rule.

- There weren't proper checks to stop filenames like ../../../../../tmp/pwned (relative paths) or even /etc/passwd (absolute path).
- So, if an attacker controls the rule source, they could potentially make Suricata overwrite important files—a classic directory traversal attack.

How Attackers Could Exploit It

Imagine you run a Suricata sensor and you import rules from an external, possibly untrusted source (maybe a community ruleset or an automatically pulled third-party rule feed).

An attacker crafts a Suricata dataset rule like this

dataset:
    type: string
    name: supersecret
    write: yes
    file: ../../../../tmp/traversal_attack

What happens?

- When this rule is triggered, Suricata actually uses the filename as provided—here, ../../../../tmp/traversal_attack.
- That means it writes to /tmp/traversal_attack—outside its intended data directory.
- Cleverly crafted rules could allow the attacker to drop files anywhere Suricata’s user has permissions, potentially leading to data loss, code execution, or escalating the attack further.

Absolute paths are also possible

dataset:
    type: string
    name: rootpwnd
    write: yes
    file: /etc/passwd

This would try to overwrite /etc/passwd (it’ll fail if Suricata doesn’t have permission—but you see how dangerous this could be).

Here's an example of just how simple the attack is

# malicious.rules
dataset:
    type: string
    name: hackdataset
    write: yes
    file: ../../../../tmp/pwned_by_cve35852

And a Suricata rule using it

alert http any any -> any any (msg:"Test dataset traversal"; dataset:set,hackdataset,write; sid:1000001; rev:1;)

An attacker gets you to load these into your Suricata instance.

- On traffic that triggers this rule, Suricata creates or modifies /tmp/pwned_by_cve35852 instead of a local, safe dataset file.

Real-World Attack Scenario

Let's say you're using community-contributed rules for Suricata, or you have an automated process to download updates. By slipping a malicious dataset rule into this stream, an attacker could:

How Did Suricata Fix CVE-2023-35852?

Starting in Suricata 6..13 (release notes), a fix was introduced to limit this behavior.

Now, to use absolute paths or to allow writing via datasets, you must explicitly allow this in your suricata.yaml config, like so:

dataset:
  allow-absolute-filenames: true
  allow-write: true

- If these are not set, Suricata blocks attempts to use absolute paths or perform unauthorized writes.
- This means random rules can’t sneak file writes anywhere anymore, unless the admin specifically allows it (and understands the risk).

Update Suricata

If you’re using any version before 6..13, update ASAP. You can download the latest from Suricata’s site.

2. Audit/verify rules sources
Always ensure you trust the sources of your rules files—random rules from the Internet are dangerous!

Review config settings

Only enable allow-absolute-filenames or allow-write if you *really* need them, and understand the risks.

References

- NVD CVE-2023-35852 entry
- Suricata 6..13 Release Announcement
- Suricata Github Issue #8348 (fix details)

Conclusion

CVE-2023-35852 is a great example of how even small oversights—like not properly sanitizing a filename—can lead to serious vulnerabilities in complex software like Suricata. If you’re running Suricata (especially with any kind of automatic, external rule updating), *don’t ignore this bug*!

Patch your system, lock down your config, and always think twice about the source of your security rules. Stay safe out there!


*If you found this article helpful, consider sharing it with your network or posting questions below.*

Timeline

Published on: 06/19/2023 04:15:00 UTC
Last modified on: 06/28/2023 18:44:00 UTC