Bug #1674
closedCannot use 'tag:session' after base64_data keyword
Description
When setting tag:session after using a base64_data, Suricata complains. It works if you remove the tag:session, or move to before the base64_data key word. The position of tag:session should be irrelevant, as this is a post-detection rule option.
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"some b64thing"; flow:established,from_server; file_data; content:"sometext"; fast_pattern; base64_decode:relative; base64_data; content:"foobar"; nocase; tag:session,120,seconds; classtype:bad-unknown; sid:1111111; rev:1;)
duane@testbox:~$ suricata -c /etc/suricata/suricata.yaml -S b64.rules -T 22/1/2016 -- 19:31:44 - <Info> - Running suricata under test mode Initialization syslog logging with format "[%i] <%d> -- ". 22/1/2016 -- 19:31:44 - <Notice> - This is Suricata version 3.0RC2 RELEASE 22/1/2016 -- 19:31:44 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Rule buffer cannot be reset after base64_data. 22/1/2016 -- 19:31:44 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"some b64thing"; flow:established,from_server; file_data; content:"sometext"; fast_pattern; base64_decode:relative; base64_data; content:"foobar"; nocase; tag:session,120,seconds; classtype:bad-unknown; sid:1111111; rev:1;)" from file b64.rules at line 1 ______________________________________________________________________
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"some b64thing"; flow:established,from_server; file_data; content:"sometext"; fast_pattern; base64_decode:relative; base64_data; content:"foobar"; nocase; classtype:bad-unknown; sid:1111111; rev:1;)
duane@testbox:~$ suricata -c /etc/suricata/suricata.yaml -S b64.rules -T 22/1/2016 -- 19:32:05 - <Info> - Running suricata under test mode Initialization syslog logging with format "[%i] <%d> -- ". 22/1/2016 -- 19:32:05 - <Notice> - This is Suricata version 3.0RC2 RELEASE <snip> 22/1/2016 -- 19:32:05 - <Notice> - Configuration provided was successfully loaded. Exiting. ______________________________________________________________________
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"some b64thing"; flow:established,from_server; file_data; content:"sometext"; fast_pattern; tag:session,120,seconds; base64_decode:relative; base64_data; content:"foobar"; nocase; classtype:bad-unknown; sid:1111111; rev:1;)
duane@testbox:~$ suricata -c /etc/suricata/suricata.yaml -S b64.rules -T duane@testbox:~$ sudo /usr/local/bin/suricata -c /etc/suricata/suricata.yaml -S b64.rules -T 22/1/2016 -- 19:40:41 - <Info> - Running suricata under test mode Initialization syslog logging with format "[%i] <%d> -- ". 22/1/2016 -- 19:40:41 - <Notice> - This is Suricata version 3.0RC2 RELEASE <snip> 22/1/2016 -- 19:40:41 - <Notice> - Configuration provided was successfully loaded. Exiting.
Updated by Victor Julien almost 9 years ago
- Description updated (diff)
- Status changed from New to Assigned
- Assignee set to Jason Ish
- Target version set to 70
Updated by Jason Ish almost 9 years ago
Victor Julien: Do you think it might make sense to reorder DetectSigMatchListEnum (https://github.com/inliniac/suricata/blob/master/src/detect.h#L83) with detect lists first, then post-detection lists? Then add a demarcation point, DETECT_SM_LIST_DETECT_MAX so the sanity check can easily determine detection lists from non detect/post detect lists?
Updated by Victor Julien almost 9 years ago
Jason that seems risky wrt performance effects and possible other side effects.
Updated by Jason Ish almost 9 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.0.1
Updated by Victor Julien almost 9 years ago
- Target version changed from 3.0.1 to 3.0.1RC1