Bug: Multiple instances of rule options fields clobber eachother

[andrewbolster]

Bug: Multiple instances of rule options fields clobber eachother

[sevdog]

I dont get the use case in which this could be misleading or considered as a bug.

Could you please explain this?

[andrewbolster]

In the example above the signature has multiple content fields;

 {'name': 'content', 'value': '"|55 04 03|"'},
 {'name': 'content', 'value': '"|0f|directory92.com"'},

But the parsed rule object only presents the last one;
{'content':'"|0f|directory92.com"'},

[sevdog]

IMO its some kind of unwanted bug caused by this line of code:

# omissis
else:
    rule[name] = val
# omissis

If you better inspect the parsed rule you can also note these other values which do not make sense in that place:

 'distance': '1',
 'within': '16',
 'tag': 'session,5,packets'

If you need to check for content options its better to inspect the options key.

A fix can be done easily by removing that line of code.

Maybe @jasonish this could be pointed out also in suricata-update.

[jasonish]

Yes, the fix will be to remove the field from the decode rules and loop through the options.

This stuff has been removed from suricata-update already as its not relevant to that app.