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 10 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 10 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 10 years ago
Jason that seems risky wrt performance effects and possible other side effects.
Updated by Jason Ish almost 10 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.0.1
Updated by Victor Julien over 9 years ago
- Target version changed from 3.0.1 to 3.0.1RC1