Project

General

Profile

Actions

Bug #6483

closed

http.request_headers - odd behavior with multiple signtures

Added by Brandon Murphy about 1 year ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Description

When testing multiple iterations of a signature which contained http.request_headers, I found that enabling one signature, which should not alert, caused another signature, which should alert, to not alert.

Reproduction steps

1. Using Suricata version 7.0.3-dev (46a46e5b1 2023-11-07) enable the following rules

## contains trailing |0d 0a| in pcre and does not fire, and should not fire, but when this rule is enabled, causes sid:3 to not fire
alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.method; content:"GET"; http.uri; content:"/ws"; endswith; http.user_agent; content:"Go|2d|http|2d|client|2f|1|2e|1"; http.connection; content:"Upgrade"; bsize:7; http.request_header; content:"Key|3a 20|"; startswith; pcre:"/^(?:[a-z0-9]{64})\x0d\x0a/R"; sid:2;)

## doesn't contain |0d 0a|, should fire and fires by itself, but not when above rule is enabled.
alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.method; content:"GET"; http.uri; content:"/ws"; endswith; http.user_agent; content:"Go|2d|http|2d|client|2f|1|2e|1"; http.connection; content:"Upgrade"; bsize:7; http.request_header; bsize:69; content:"Key|3a 20|"; startswith; pcre:"/^(?:[a-z0-9]{64})$/R"; sid:3;)

2. Run Suricata against the attached pcap
3. Observe that no alerts are produced
4. Now disable sid:2
5. Observe that sid:3 now alerts

Expected Behavior

Sid:3 should alert regardless of the state of sid:2;

Observations

if the \x0d\x0a is removed from sid:2, sid:2 and sid:3 fires as expected

The following rule which uses http.header alerts fine, this appears to isolate the issue to http.request_header

## uses http.header and should fire.  Does fire regardless of other rules
alert http $HOME_NET any -> $EXTERNAL_NET any (flow:established,to_server; http.method; content:"GET"; http.uri; content:"/ws"; endswith; http.user_agent; content:"Go|2d|http|2d|client|2f|1|2e|1"; http.connection; content:"Upgrade"; bsize:7; http.header; content:"Key|3a 20|"; pcre:"/^(?:[a-z0-9]{64})\x0d\x0a/R"; sid:20;)


Files

request_header.pcap (673 Bytes) request_header.pcap Brandon Murphy, 11/10/2023 04:20 AM

Related issues 2 (0 open2 closed)

Related to Suricata - Security #6441: detect: heap use after free with http.request_header keywordClosedPhilippe AntoineActions
Related to Suricata - Bug #6736: http.request_header and http.response_header behavior with HTTP1 trafficClosedPhilippe AntoineActions
Actions #1

Updated by Brandon Murphy 9 months ago

  • Description updated (diff)
Actions #2

Updated by Victor Julien 9 months ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine
Actions #3

Updated by Philippe Antoine 9 months ago

  • Status changed from Assigned to Resolved
  • Target version changed from TBD to 8.0.0-beta1

I do not get the bug anymore cf https://github.com/OISF/suricata-verify/pull/1648

Likely a duplicate of #6441 and #6736

Actions #4

Updated by Philippe Antoine 9 months ago

  • Related to Security #6441: detect: heap use after free with http.request_header keyword added
Actions #5

Updated by Philippe Antoine 9 months ago

  • Related to Bug #6736: http.request_header and http.response_header behavior with HTTP1 traffic added
Actions #6

Updated by Brandon Murphy 9 months ago

Confirmed. I'm not able to reproduce this behavior on 8.0.0-dev (41a621178 2024-02-14) or 7.0.3

Actions #7

Updated by Victor Julien 9 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF