Bug #5176
openFalse positive when negated content is far ahead of matching content.
Description
In looking at alerts for a signature designed to detect powershell command line options returned by http servers, but not part of an HTML page, many false positives were discovered. I have been able to able to reliability reproduce the False Positive alert with the attached pcap gathered from any.run.
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"test with http buffers - SHOULD NOT ALERT"; flow:established,from_server; http.response_body; content:!"<html"; content:"-ExecutionPolicy"; nocase; sid:1;)
Files
Updated by Jeff Lucovsky over 2 years ago
I've confirmed that alerts are generated on
- master-5.0.x
- master-6.0.x
- master
Updated by Victor Julien over 2 years ago
Initial analysis:
content:"-ExecutionPolicy"; is the fast_pattern.
Engine buffers up initial response body to ~40k, then inspects rest in smaller 16k chunks.
Chunk at offset ~83k hits contains the fast pattern.
Inspection then checks for the content:!"<html"; condition, but since it only has bytes ~83k to ~99k, it won't find it because its before the window.
FP can be avoided by anchoring the content:!<html"; startswith;. But this doesn't actually check the pattern, it just fails to match as we don't have data at offset 0.