Project

General

Profile

Actions
Copy link

Bug #3190

closed

file_data inspection inhibited by additional (non-file_data) content match rule

Added by Gabriel Somlo over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Victor Julien
Target version:
5.0.0
Affected Versions:
5.0rc1
Effort:
Difficulty:
Label:

Description

Following this fix: https://github.com/OISF/suricata/pull/4211/commits/d4bc46038133a26ac0010ef64c865746f95814c7,
file_data base64 mail attachment content inspection started working (see #2395)
on the sample pcap here: https://redmine.openinfosecfoundation.org/attachments/1560
when this single relevant example rule was present: https://redmine.openinfosecfoundation.org/attachments/1748

The problem is that, when a second content-matching rule is also present, as in: https://redmine.openinfosecfoundation.org/attachments/1793,
the file_data rule no longer fires (both rules should generate alerts on the sample pcap file)!

Opening new bug since
1. I don't know whether this is the same underlying root cause as #2395 itself, and
2. my redmine account apparently doesn't have the power to re-open a closed bug :)

Related issues 2 (0 open — 2 closed)

Related to Suricata - Bug #2395: File_data inspection depth while inspecting base64 decoded dataClosedVictor JulienActions
Related to Suricata - Bug #2522: The cross-effects of rules on each other, without the use of flowbits.ClosedVictor JulienActions
Actions
Copy link
 #1

Updated by Victor Julien over 5 years ago

  • Related to Bug #2395: File_data inspection depth while inspecting base64 decoded data added
Actions
Copy link
 #2

Updated by Victor Julien over 5 years ago

  • Affected Versions deleted (4.0beta1)

It would be good to have a suricata-verify test for this case as well.

Actions
Copy link
 #3

Updated by Gabriel Somlo over 5 years ago

Turns out, my redmine account also doesn't have the power to fix the "affected version" field which should be '5.0rc', i.e., "the latest, greatest, and shiniest currently available". Apologies for that mistake!

Actions
Copy link
 #4

Updated by Gabriel Somlo over 5 years ago

Actions
Copy link
 #5

Updated by Andreas Herz over 5 years ago

  • Assignee set to Gabriel Somlo
  • Target version set to 5.0.0
  • Affected Versions 5.0beta1 added
Actions
Copy link
 #6

Updated by Andreas Herz over 5 years ago

  • Status changed from New to Assigned
Actions
Copy link
 #7

Updated by Victor Julien over 5 years ago

  • Related to Bug #2522: The cross-effects of rules on each other, without the use of flowbits. added
Actions
Copy link
 #8

Updated by Victor Julien over 5 years ago

  • Assignee changed from Gabriel Somlo to Victor Julien

I've done a bit of investigating and it seems this is the same issue as #2522, but then for SMTP. This makes sense, as the fix was only implemented for HTTP.

Actions
Copy link
 #9

Updated by Victor Julien over 5 years ago

  • Affected Versions 5.0rc1 added
  • Affected Versions deleted (5.0beta1)
Actions
Copy link
 #10

Updated by Victor Julien about 5 years ago

  • Status changed from Assigned to Closed
Actions
Copy link

Also available in: Atom PDF