Project

General

Profile

Actions
Copy link

Bug #437

closed
VJ CT

filemagic / libmagic inconsistent between releases

Bug #437: filemagic / libmagic inconsistent between releases

Added by Victor Julien about 14 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Community Ticket
Target version:
TBD
Affected Versions:
Effort:
Difficulty:
Label:

Description

See http://permalink.gmane.org/gmane.comp.security.ids.snort.emerging-sigs/15224

The issue is that the installed libmagic versions can return different results for the same file. This doesn't make libmagic/filemagic useless, but it does make it very hard to use for a ruleset like ET.

Possible solutions:
- ship/integrate libmagic so we always use the right version
- ship our own set of definitions for each libmagic version
- write our own file identify code (http://www.garykessler.net/library/file_sigs.html)

Related issues 2 (1 open — 1 closed)

Related to Suricata - Feature #886: bromagic supportClosedActions
Related to Suricata - Feature #5894: file: file classification keywordFeedbackVictor JulienActions

VJ Updated by Victor Julien almost 14 years ago Actions
Copy link
 #1

  • Status changed from New to Assigned
  • Assignee set to Victor Julien
  • Target version set to TBD

AH Updated by Andreas Herz over 10 years ago Actions
Copy link
 #2

Is this still an issue? Maybe we could gather a list of versions running on the distros to compare the file info.

PM Updated by Peter Manev over 10 years ago Actions
Copy link
 #3

The challenge here is that this is OS/libmagic version dependent(that changes dynamically) - if we start generating and cross referencing lists we might find ourselves into administrative nightmare I fear.

I like Victor's first suggestion (above) in terms of consistency.
Thoughts?

AH Updated by Andreas Herz about 10 years ago Actions
Copy link
 #4

Some related informations also in #1268

VJ Updated by Victor Julien about 9 years ago Actions
Copy link
 #5

  • Status changed from Assigned to New
  • Assignee changed from Victor Julien to OISF Dev

AH Updated by Andreas Herz almost 9 years ago Actions
Copy link
 #6

AH Updated by Andreas Herz almost 9 years ago Actions
Copy link
 #7

Would this solve #886 as well or did you have something else in mind with that ticket?

VJ Updated by Victor Julien over 7 years ago Actions
Copy link
 #8

  • Assignee changed from OISF Dev to Anonymous

AH Updated by Andreas Herz about 7 years ago Actions
Copy link
 #9

  • Assignee set to Community Ticket

AH Updated by Andreas Herz over 6 years ago Actions
Copy link
 #10

  • Status changed from New to Feedback

Ping to team for feedback :)

VJ Updated by Victor Julien about 3 years ago Actions
Copy link
 #11

  • Related to Feature #5894: file: file classification keyword added

PA Updated by Philippe Antoine almost 3 years ago Actions
Copy link
 #12

I would say that this should be documented as a limitation (maybe it is already) and kept that way.

JF Updated by Juliana Fajardini Reichow over 2 years ago Actions
Copy link
 #13

This PR adds a note about this: https://github.com/OISF/suricata/pull/9245/files
Do we want something more elaborated?

PA Updated by Philippe Antoine over 2 years ago Actions
Copy link
 #14

  • Status changed from Feedback to Rejected

This is the intrinsic functionality of filemagic keyword and documented as such

To get something static, we should write a new keyword...

Actions
Copy link

Also available in: PDF Atom