Bug #7851
openbsize and pcre inspecting random buffers when used with http.host or http.host.raw, causing FP alerts
Description
I'll pre-face this by saying that I cannot upload PCAPs here for this bug report and can only share snippets of the offending traffic however, I can share PCAPs privately in order to test and reproduce.
bsize & pcre applied to http.host (or http.host.raw ) but are inspecting http.uri¶
I was writing a signature today that looks for suspiciously short HTTP host field values (based on https://x.com/naumovax/status/1955297617492975951) so I wrote the following:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Suspicious short host value - pcre and bsize"; flow:established,to_server; http.host; bsize:<3; pcre:"/^.{1,2}$/"; classtype:bad-unknown; sid:1; rev:1;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Suspicious short host value - bsize"; flow:established,to_server; http.host; bsize:<3; classtype:bad-unknown; sid:2; rev:1;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Suspicious short host value - pcre"; flow:established,to_server; http.host; pcre:"/^.{1,2}$/"; classtype:bad-unknown; sid:3; rev:1;)
To my surprise, these alerted on a PCAP with absolutely no Host header present. After walking through a suricata-7.0.3 debug dump, I noticed that the matches occurred on the HTTP URI buffer (for both the bsize match and the PCRE match).
Here is a snippet of that traffic (all HTTP headers here are 'Mp-*' headers, there is no 'Host' header in this request)
CONNECT / HTTP/1.1 Mp-Country: US Mp-BuildVersion: 136 Mp-Roaming: 0 Mp-VersionRelease: 4.3 Mp-Operator: android Mp-SdkId: 18 Mp-NetworkType: 3 .. trunc ..
Following the detection pointer and checking where matches are found gives us this:
ET Inspecting bsize: 3 ET -> MATCH! ET buffer->pointer: 0 00000000 2f |/ |
testing other buffers - exclusive to http.host and http.host.raw¶
From what I can gather so far, the header not being present is an issue so I tested the following keywords with the same rule logic:
http.user_agent;
http.accept;
http.accept_enc;
http.accept_lang;
http.connection;
These did not cause alerts, it seems exclusive to http.host and http.host.raw.
Updated by James Emery-Callcott 2 days ago
It seems this is more a lack of understanding on my part (lack of familiarity with CONNECT nuances) and in this scenario, this is working as intended because what I considered to be the URI '/' should actually be <host>:<port> when using 'CONNECT'.
Is this worth a documentation update stating that http.host; and http.host.raw; will also work and apply to 'CONNECT' HTTP requests but in a unique way?