Bug #3450
closedsignature with sticky buffer with subsequent pcre check in a different buffer loads but will never match
Description
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"suri 5 pcre fun"; flow:established,to_server; http.method; content:"POST"; http.uri; content:".php"; http.header; content:"|0d 0a|User-Agent|0d 0a|"; content:!"Referer|3a 20|"; pcre:"/^(?:[A-F0-9]{2}){200,}$/P";)
This rule loads in suri 5 but does not fire on pcap. It seems that the sticky buffer is set and loads the pcre within the existing sticky buffer even though we specifiy the buffer for the pcre.
If the pcre is moved to the front of the rule, the rule fires as expected, example:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"suri 5 pcre fun"; flow:established,to_server; pcre:"/^(?:[A-F0-9]{2}){200,}$/P"; http.method; content:"POST"; http.uri; content:".php"; http.header; content:"|0d 0a|User-Agent|0d 0a|"; content:!"Referer|3a 20|";)
Updated by Victor Julien almost 5 years ago
What if you reset the sticky buffer before the pcre? By adding a pkt_data; before it.
Updated by Jason Taylor almost 5 years ago
Victor Julien wrote:
What if you reset the sticky buffer before the pcre? By adding a pkt_data; before it.
Resetting with pkt_data prior to the pcre will result in the rule firing as expected. It will also work if we switch it up to use something like "http.request_body; pcre:"/^(?:[A-F0-9]{2}){200,}$/";"
Updated by Victor Julien almost 5 years ago
- Status changed from New to Assigned
- Assignee set to Jeff Lucovsky
- Target version set to 5.0.2
We should probably reject the rule based on the pcre specifying a buffer while a sticky buffer is already active.
Updated by Victor Julien almost 5 years ago
- Target version changed from 5.0.2 to 5.0.3
Updated by Jeff Lucovsky over 4 years ago
- Status changed from Assigned to In Review
Updated by Jeff Lucovsky over 4 years ago
- Status changed from In Review to Closed