Project

General

Profile

Actions

Bug #5176

open

False positive when negated content is far ahead of matching content.

Added by Brandon Murphy about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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

Actions #1

Updated by Jeff Lucovsky about 2 years ago

I've confirmed that alerts are generated on
- master-5.0.x
- master-6.0.x
- master

Actions #2

Updated by Victor Julien about 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.

Actions

Also available in: Atom PDF