Bug #4624
closedbyte_jump with negative post_offset before start of buffer failure
Description
Quoting documentation for post_offset:[post_offset] <value> After the jump operation has been performed, it will jump an additional number of bytes specified by <value>
post_offset works with negative values to jump the pointer back this value, and proceeding patterns can continue matching. It's useful as a negative distance value for relative PCRE following it in my use case.
For this bug, when the negative value sends the pointer back beyond the start of the buffer, the signature is failed. This isn't consistent with other negative jump values eg. a larger negative distance following content will still be able to match from the actual start of the buffer. This is what I expected from the post_offset.
To illustrate this with an example pcap [random_tcp.pcap]:
1. (success) Matching within the packet (bytes 5-8) and using byte_jump with post_offset -8 to move the pointer back to the start of the buffer. This is able to match.drop tcp any any -> any any ( msg:"Test"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -8; pcre:"/\x4e\x53\x4c\x4f/R"; sid:1000001; )
2. (failure) The same patterns, but using a post_offset -10 (2 bytes before the start of the buffer) will fail.drop tcp any any -> any any ( msg:"Test.2"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; pcre:"/\x4e\x53\x4c\x4f/R"; sid:1000002; )
3. (failure) Actually, even the inclusion of this larger post_offset itself is enough to fail the signature without any proceeding patterns.drop tcp any any -> any any ( msg:"Test.3"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; sid:1000003; )
4. (success) A negative distance modifier for content is successful even if it goes beyond the start of the buffer.drop tcp any any -> any any ( msg:"Test.4"; rev:1; content:"|0A 95 00 20|"; content:"|4e 53 4c 4f|"; distance:-10; sid:1000004; )
This is tested on 5.0.3.
Files