Bug #4382


fileinfo "stored: false" even if the file is kept on disk

Added by Jeff Lucovsky about 3 years ago. Updated over 2 years ago.

Target version:
Affected Versions:



We believe we found a reproducible bug in the file store code.
Basically, what happens is that some streams contain files that are correctly extracted, dumped on disk, marked as closed (not truncated), and moved from tmp/ to the filestore while the fileinfo eve-log indicates that the file was not stored. We have been observing this for a while now, and were recently able to reproduce it in lab, on Suricata 4.1.8 and Suricata 5.0.3.

This is problematic, especially if one is doing automated analysis of the extracted files and not using `write-fileinfo: yes`, because it means that the file might remain "unknown" and never be automatically analyzed.

The suricata config is nothing fancy; we kept the default config from the Ubuntu package, with file-store v2 enabled, and a very basic filemagic rule:

alert http any any -> any any (msg: "FILEMAGIC PDF document"; filemagic:"PDF document"; filestore:both,file; noalert; sid:1100008; rev:1;)

The bug can be reproduced with the attached pcap file. This is not an isolated case; we were able to reproduce it with several other streams that have similar flow profile. Specifically, after the initial handshake, the file is pushed in its entirety, without any acknowledgment, then all acknowledgment segments are sent and the connection is closed abruptly with a RST. While this way of doing TCP is dirty efficient, it remains valid.

Please reach out to us if you need any more details regarding this issue.

Thank you.

Florian Maury for ArmatureTech DevTeam


pdf_http_467659.pcap (12.3 KB) pdf_http_467659.pcap Gatewatcher Dev Team, 05/18/2020 01:12 PM

Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #3703: fileinfo "stored: false" even if the file is kept on diskClosedVictor JulienActions
Actions #1

Updated by Jeff Lucovsky about 3 years ago

  • Copied from Bug #3703: fileinfo "stored: false" even if the file is kept on disk added
Actions #2

Updated by Victor Julien almost 3 years ago

  • Target version changed from 5.0.7 to 5.0.8
Actions #3

Updated by Victor Julien over 2 years ago

  • Status changed from Assigned to Rejected

The changes to fix this issue are quite intrusive, so we consider the risk too high for the 5.0.x branch. Upgrade to 6+ is the way to address this.


Also available in: Atom PDF