Snort mailing list archives

Re: File magic rules for 2.9.6, what options are required?


From: Victor Roemer <vroemer () sourcefire com>
Date: Fri, 27 Dec 2013 17:22:11 -0500

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 () gentoo org> 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 () gentoo org> 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 () 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!

Attachment: file_magic.conf
Description:

------------------------------------------------------------------------------
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 () 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!

Current thread: