Bug #7638
opendetect: incorrect rule ordering with more complex flowbit chains
Description
alert http any any -> any any (http.uri; content:"down"; flowbits:set,uritest; sid:11;) alert http any any -> any any (http.user_agent; content:"Mozilla"; flowbits:isset, headtest; flowbits:set,moz; sid:10;) alert http any any -> any any (http.method; content:"GET"; flowbits:isset,uritest; flowbits:set,headtest; sid:12;) alert http any any -> any any (http.host; content:"ether"; flowbits:isset,moz; sid:14;)
should be ordered: 11, 12, 10, 14. Is actually ordered: 11, 10, 12, 14. This is because in the ordering there just 3 cases:
set, read, read_set. Sid 10 and 12 are both read_set, and thus correct order isn't enforced.
Updated by Victor Julien 3 months ago
Updated by Shivani Bhardwaj 26 days ago
- Status changed from Assigned to In Progress
- Difficulty set to medium
Updated by Shivani Bhardwaj 12 days ago
- Target version changed from 8.0.0-rc1 to 8.0.0
This turned out to be more than just choosing and applying a correct sorting order. Isolating this problem was not a good idea.
Updated by Shivani Bhardwaj 9 days ago
- Priority changed from Normal to High
- Target version changed from 8.0.0 to 8.0.0-rc1
- Difficulty changed from medium to high
I think I am more confident now that this is actually indeed a boolean satisfiability problem. These class of problems are unsolvable in polynomial time for more than 2 conditions. A demo for 2-SAT problem is given here: https://www.geeksforgeeks.org/2-satisfiability-2-sat-problem/
Note that we can always run into "unsatisfiable" data paths. For example, the engine accepts the following complex flowbit chains but there's no way to determine the correct order for these as there isn't one:
alert http any any -> any any (http.user_agent; content:"Mozilla"; flowbits:isset, headtest; flowbits:set,moz; sid:10;)
alert http any any -> any any (http.method; content:"GET"; flowbits:set,headtest; flowbits:isset,moz; sid:12;)
So, what we can do is:
1. Apply some restrictions to reduce the number of checks. e.g. cyclic dependencies like in the above mentioned example must be disallowed resulting in errors/commenting of all rules involved.
2. Create a cycle free many to many relationship internal table. i.e. b/w signatures and flowbits.
I'm currently working on listing out the possible restrictions that could/should be applied and what should the relationship table look like.
Updated by Shivani Bhardwaj 9 days ago
- Target version changed from 8.0.0-rc1 to 8.0.0
Updated by Victor Julien 8 days ago ยท Edited
- Target version changed from 8.0.0 to 9.0.0-beta1
I think it makes sense to start with banning cyclical dependencies, as they can't be satisfied at runtime anyway. Perhaps we should create subtickets for the distinct steps.