[Snort-devel] File magic rules for 2.9.6, what options are required?
kumba at ...2185...
Fri Dec 27 16:39:20 EST 2013
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
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).
> 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
More information about the Snort-devel