On 15-June-2023 the OISF announced a new release of Suricata (6.0.13) which fixes a potential security issue that could lead to supply chain attacks against Suricata. Specifically, this pertains to signatures which use datasets or Lua. Two CVEs were issued for these vulnerabilities. See links below:
CVE-2023-35852 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35852
CVE-2023-35853 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35853
Suricata 6.0.13 patches these vulnerabilities.
Here is the release notification: https://forum.suricata.io/t/suricata-6-0-13-released/3595
The Stamus Networks team actually discovered the vulnerability and Stamus Security Platform (SSP) users were already protected against these newly-announced Suricata supply chain vulnerabilities with the U39 release issued in April 2023.
You can read about the U39 release here: https://www.stamus-networks.com/blog/u39-for-stamus-security-platform-now-available
The intrusion detection (IDS) functionality of Suricata is dependent on signatures to power the detections. Historically, organizations have deployed a set of rules from a reputable source (such as ETPro and/or ETOpen) alongside some custom rules developed in house. With the proliferation of multiple valuable sources of threat intelligence and rulesets, a modern Suricata deployment often involves rulesets from multiple sources sourced from the internet or from community platforms like MISP
This shift away from a trusted central provider \means the quality and security of these signatures can not be trusted by default. This is because Suricata is not simply a pattern matching engine.
One of the lesser-known features of Suricata is its support for the powerful Lua scripting language. Is it built by default by some distributions like Debian. This Lua support gives Suricata the capability of running a Lua script from within a signature.
Lua is a powerful language and script execution is not sandboxed, so system interactions such as writing files or communicating over the network is possible. This means that a signature using Lua can run arbitrary code as the user running Suricata. This was a deliberate design choice, but the change in availability of untrusted signature sources requires that we revisit this decision and the implementation.
On top of that, Stamus Networks researchers uncovered another vulnerability relating to datasets. In releases prior to Suricata 6.0.13, the dataset feature could be abused by a signature to overwrite arbitrary files on the system.
Combining the fact that source of signatures can not be all trusted and the fact that some features of Suricata are potentially dangerous, we need to revisit the way the ruleset source management is performed. Giving unfettered access to all Suricata features is no longer safe.
At minimum, some features like Lua script execution and dataset save (before Suricata 6.0.13) must be disabled on sources we cannot trust.
Beginning with update 39 (U39, announced in April 2023), Stamus Security Platform (SSP) and SELKS give users the ability to protect against these potential supply chain vulnerabilities. The protection takes place in Stamus Security Platform and SELKS using the "Source sanitization" configuration option on the ruleset “Source” page.
NOTE: this option is enabled by default so you will need to disable it for your own signatures or for your most trusted sources.
See the screenshot below.
A fix for this issue was announced by the OISF on June 15, 2023. Suricata 6.0.13 will provide a flag to disable Lua rules when Lua is compiled in. With 6.0.13, absolute filenames and filenames attempting parent directory traversal using ".." will not be allowed by default. And finally, 6.0.13 adds 2 additional configuration parameters to Suricata:
Here is the release notification: https://forum.suricata.io/t/suricata-6-0-13-released/3595