[Snort-devel] File magic rules for 2.9.6, what options are required?
Joel Esler (jesler)
jesler at ...3461...
Fri Dec 27 12:10:58 EST 2013
This is great feedback.
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.
> - 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.
>> 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:
>>> With these being optional:
>>> 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