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

Joshua Kinard kumba at ...2185...
Fri Dec 27 11:13:05 EST 2013


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.

- 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.

- '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.

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.

Thanks!,

--J


> 
> Sent from my iPhone.  
> 
>> On Dec 26, 2013, at 15:45, "Joshua Kinard" <kumba at ...2185...> wrote:
>>
>>
>> Doing a quick glance at the new file magic "rules" that one can specify in
>> 2.9.6 RC, I am not directly seeing a definition of which of the options are
>> required and which aren't.
>>
>> So far, it looks like I can write this:
>>    file type:FOO;
>>
>> And ~/bin/snort -c local.rules -T parses w/o error.
>>
>> Logically, my guess is that the following option keywords are going to be
>> required for a 'file' definition to work correctly:
>>    type
>>    id
>>    msg
>>    content
>>
>> With these being optional:
>>    ver
>>    category
>>    group (required only if >1 definition of 'type')
>>    offset (assumed 0 if not specified)
>>    rev (assumed 1 if not specified)
>>
>> Does this sound about right?





More information about the Snort-devel mailing list