Actions
Security #2231
closedRedundant content checks may cause Suricata DoS condition on a insignificant traffic rate
Git IDs:
1a39ab99f330710311216e6bee657d263da393b7
7419bb2bace4f6763095773f3c5ed72aa8d852b3
Severity:
Disclosure Date:
Description
It is possible to make Suricata to perform lots of redundant checks on a content against a specially crafted network traffic with a certain signature. Search engine doesn't stop when it should after no match found and ends only on reaching inspection-recursion-limit (3000 by default).
This issue was fixed in 4.0 branch likely with the following fix: https://redmine.openinfosecfoundation.org/issues/2101
Results of scanning a crafted PCAP against ET Open signature sid:2016204
Suricata 3.2.x-master:
Stats for: total -------------------------------------------------------------------------------------------------------------------------------- Keyword Ticks Checks Matches Max Ticks Avg Avg Match Avg No Match ---------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- content 5479828 1510 1501 225789 3629.00 3632.00 3089.00 pcre 3836615439 1491 0 17232405 2573182.00 0.00 2573182.00 --------------------------------------------------------------------------------------------------------------------------------
Suricata 4.0:
Stats for: total -------------------------------------------------------------------------------------------------------------------------------- Keyword Ticks Checks Matches Max Ticks Avg Avg Match Avg No Match ---------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- content 19060 4 3 8164 4765.00 5374.00 2936.00 pcre 2938616 1 0 2938616 2938616.00 0.00 2938616.00 --------------------------------------------------------------------------------------------------------------------------------
I've attached a sample pcap that I used for experiments
Files
Updated by Victor Julien about 7 years ago
- Description updated (diff)
- Status changed from New to Assigned
- Assignee set to Victor Julien
Updated by Victor Julien about 7 years ago
- Status changed from Assigned to Closed
- Priority changed from High to Normal
Updated by ajaxtpm ajaxtpm about 7 years ago
CVE-2017-15377 was requested for this flaw.
Updated by Victor Julien about 4 years ago
- Tracker changed from Bug to Security
- CVE set to 2017-15377
- Git IDs updated (diff)
Actions