Project

General

Profile

Actions

Bug #1426

closed

Files prematurely truncated by detection engine even though force-md5 is enabled

Added by Ray Ruvinskiy almost 10 years ago. Updated almost 10 years ago.

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

Description

I'm using suricata 2.0, running with force-md5 and the Emerging Threats ruleset. I've noticed behaviour that I can't understand. Under some circumstances, files end up being prematurely truncated, and therefore the MD5 hash does not encompass as much of the file as I would like.

The truncation happens because FileDisableStoringForTransaction is called, specifically with the following stack trace:

#0  FileCloseFilePtr (ff=0x7f02ecec05b0, data=0x0, data_len=0, flags=33 '!') at util-file.c:560
#1 0x0000000000567535 in FileDisableStoringForTransaction (f=<optimized out>, direction=<optimized out>, tx_id=0) at util-file.c:822
#2 0x00000000004af7ea in DeStateDetectStartDetection (tv=0xae87890, de_ctx=0x3c4ac30, det_ctx=0x7f02ec001c50, s=<optimized out>, p=0x378c6e0, f=0x39665b0, flags=8 '\b', alstate=0x7f02ecec2030,
alproto=1, alversion=2) at detect-engine-state.c:441
#3 0x000000000047dfb7 in SigMatchSignatures (th_v=0xae87890, de_ctx=0x3c4ac30, det_ctx=0x7f02ec001c50, p=0x378c6e0) at detect.c:1513
#4 0x000000000047e1f5 in Detect (data=<optimized out>, p=<optimized out>, tv=<optimized out>, pq=<optimized out>, postpq=<optimized out>) at detect.c:1711
#5 Detect (tv=<optimized out>, p=<optimized out>, data=<optimized out>, pq=<optimized out>, postpq=<optimized out>) at detect.c:1683
#6 0x000000000054b328 in TmThreadsSlotVarRun (tv=0xae87890, p=0x378c6e0, slot=<

This happens after FileOpenFile but before FileAppendData, so anything written out with FileAppendData is excluded.

I'm struggling wrapping my head around the detection engine code sufficiently to understand what's going on. I'd appreciate assistance in debugging this. Thanks!

Actions #2

Updated by Ray Ruvinskiy almost 10 years ago

Thanks, that did the trick!

Out of curiosity, could you please explain under what circumstances FileDisableStoringForTransaction is called?

Actions #3

Updated by Victor Julien almost 10 years ago

  • Status changed from New to Closed
  • Assignee set to Victor Julien
  • Target version set to 2.1beta4
  • % Done changed from 0 to 100

It's called when the detection engine determines that no 'filestore' rules have a chance of matching for a file.

Thanks for testing!

Actions

Also available in: Atom PDF