[Snort-devel] File magic rules for 2.9.6, what options are required?

Victor Roemer vroemer at ...402...
Fri Dec 27 17:22:11 EST 2013


Joshua,

Sorry for all the confusion, I'll try to answer you questions best I can.

1.  You can configure multiple "content" keywords in a file magic rule.

2.  The "ver" keyword (used in the file magic rule) is usable with the
"file_type" keyword in regular Snort rules.

Given the example:

E.g., Given these file magic rules:
> file type:PDF; id:42; ver:1.4; group:pdf; msg:"PDF v1.4"; content:|25 50 44
> 46 2d 31 2e 34|; rev:1;
> file type:PDF; id:43; ver:1.5; group:pdf; msg:"PDF v1.5"; content:|25 50 44
> 46 2d 31 2e 35|; rev:1;
> Then, "file_type:PDF,1.5;" would match the second one?


You are correct.

3. Syntax for "content" is currently limited to supporting only the pipe
block hex characters (i.e., '|00 01 02|'). I believe accepting plain ascii
would be a good future enhancement.

4. Attached is the Sourcefire "file_magic.conf" that contains a load of
rules for identifying file types. When we originally put this together, the
"ver" keyword was, at the time, not used.

We had intended on releasing this file with the Snort 2.9.6 beta package,
however we will be releasing this with 2.9.6 proper when the time comes.



On Fri, Dec 27, 2013 at 4:39 PM, Joshua Kinard <kumba at ...2185...> wrote:

> On 12/27/2013 1:52 PM, Hui Cao wrote:
> > Hi Joshhua,
> >
> > Thanks for the great feedbacks.
> >
> > In general, file magic rule should be relative stable, so we just keep
> > file magic rule syntax simple on this release. Please see my comments
> > inline.
>
> Another question: Can there be multiple content/offset keywords per file
> magic rule?  It looks like ParseFileContent is setting up a linked list of
> MagicData structs, with each MagicData struct holding an offset int, magic
> pattern, and pattern length.
>
> If that's the case...are subsequent contents relative to each other?  Or at
> that point, does 'offset' have to be specified for all subsequent contents
> so that the patterns are correctly matched in the packet data?  I am
> assuming this code has nothing like the doe_ptr and such, and that it
> carries an implicit depth (the length of the pattern, after the hex is
> converted to actual bytes).
>
> --J
>
>
>
> > On 12/27/2013 12:10 PM, Joel Esler (jesler) wrote:
> >> This is great feedback.
> >>
> >> --
> >> Joel Esler
> >> Intelligence Lead
> >> Open Source Manager
> >> Vulnerability Research Team
> >>
> >> Sent from my iPhone.
> >>
> >>> On Dec 27, 2013, at 11:13, "Joshua Kinard" <kumba at ...2185...> wrote:
> >>>
> >>>> On 12/26/2013 10:16 PM, Joel Esler (jesler) wrote:
> >>>> Thanks Joshua, one of the devels will get back to you.
> >>> Couple of additional questions/ideas:
> >>>
> >>> - 'content' keyword should be a quoted string and optionally allow
> ASCII.  I
> >>> can see why the initial draft is to allow hexadecimal only, but one
> finds
> >>> that a lot of file magics use printable ASCII.  I.e., "%PDF-1." for
> PDF,
> >>> "ELF" for Linux/Unix ELF executables, classic "MZ" for PE executables.
> > Yes, this is a nice feature.
> >>> - This specification doesn't appear to handle cases like PE
> executables,
> >>> where sometimes checking for "MZ" alone is not enough.  You'll still
> want to
> >>> use a byte_jump to reach the start of the PE header to really verify
> that
> >>> you're dealing with a PE executable.  But I understand this is a first
> cut
> >>> of this feature, so it'll probably get beefed up in the future.  That
> and a
> >>> flowbit setter rule for PE executables is trivial enough.
> > File magic will give you the most likely file type. If you want the
> > precise file type, you can use flowbit.  We try to limit the performance
> > impact of file type identification.
> >>> - 'category' appears to be an unquoted string, but the example
> documentation
> >>> suggests it can, and cannot, accept spaces.  The second sentence
> implies no
> >>> whitespace, while the third sentence implies it does:
> >>>
> >>>     category: defines the categories of file type. Name
> >>>     should be limited to any alphanumeric string including
> >>>     periods, dashes, and underscores. Categories can be
> >>>     Executables, PDF files, FLASH files, Office Documents,
> >>>     Archive, Graphics, Multimedia etc.
> > Currently, category is used for document purpose.  It can accept spaces.
> >>> I'd suggest making category take a quoted string if whitespace is
> going to
> >>> be allowed.  This'll avoid easily-made syntax errors when people start
> >>> writing these things.
> >>>
> >>> - ver: unquoted string, right?  The source suggests such.
> > Currently, ver is used for document purpose
> >>> Thanks!,
> >>>
> >>> --J
> >>>
> >>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20131227/8d43fb06/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file_magic.conf
Type: application/octet-stream
Size: 20894 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20131227/8d43fb06/attachment.obj>


More information about the Snort-devel mailing list