Bug #158
closedbyte_test + relative modifer doesn't work when previous keyword is byte_jump
Description
Suricata does not support byte_test,relative when the previous keyword is byte_jump. This is supported in snort and works. We should support the same.
alert tcp any any -> any any (msg:"content + byte_test + relative"; byte_jump:1,44,string,dec; byte_test:1,=,0,0,relative,string,dec; classtype:bad-unknown; sid:777; rev:1;)
src/suricata -s blah.rules -r /home/coz/rules4/allworkandnoplayplain.pcap -l ./ -c suricata.yaml
[17457] 13/5/2010 -- 13:05:29 - (detect-bytetest.c:538) <Error> (DetectBytetestSetup) -- [ERRCODE: SC_ERR_BYTETEST_MISSING_CONTENT(104)] - relative bytetest match needs a previous content option
[17457] 13/5/2010 -- 13:05:29 - (detect.c:297) <Error> (DetectLoadSigFile) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(37)] - Error parsing signature "alert tcp any any -> any any (msg:"content + byte_test + relative"; byte_jump:1,44,string,dec; byte_test:1,=,0,0,relative,string,dec; classtype:bad-unknown; sid:777; rev:1;)" from file blah.rules at line 1
Files
Updated by Gurvinder Singh over 14 years ago
- Assignee changed from OISF Dev to Gurvinder Singh
Updated by Gurvinder Singh over 14 years ago
- File 0002-support-setting-up-byte_test-relative-when-byte_jumo.patch 0002-support-setting-up-byte_test-relative-when-byte_jumo.patch added
- File 0003-support-setting-up-byte_jump-relative-when-byte_test.patch 0003-support-setting-up-byte_jump-relative-when-byte_test.patch added
- Status changed from New to Resolved
- % Done changed from 0 to 90
Attached is a patch which fixes the issue. It is incremental to the bug 142. I wonder Will, does the following signature is valid or not
alert tcp any any -> any any (msg:"content + byte_test + relative"; byte_test:1,=,0,0,relative,string,dec; byte_jump:1,44,string,dec; classtype:bad-unknown; sid:777; rev:1;)
If it is valid, then I have attached another patch for the same, otherwise don't apply the last patch.
Updated by Will Metcalf over 14 years ago
Are you asking if the case is valid where there is no previous match for the first byte_test with relative? In snort if a relative option is passed to byte_test and there is no previous match it will start from the beginning of the payload. With that said, I don't agree with this behavior and I think we should tell the user that the signature is wrong and produce an error as it is probably a typo.
Updated by Gurvinder Singh over 14 years ago
Ah it seems I made the typo, when asking you about the signature validity. The correct signature which I ask about is
alert tcp any any -> any any (msg:"content + byte_test + relative"; byte_test:1,=,0,0,string,dec; byte_jump:1,44,relative,string,dec; classtype:bad-unknown; sid:777; rev:1;)
Updated by Will Metcalf over 14 years ago
No this is not supported. Snorts behavior here is that byte_jump,relative would be from the beginning of the payload as byte_test doesn't move doe_ptr. Once again no message is displayed to the user, snort "assumes" this is what you meant. We should reject this rule as it will probably not behave in the way that the author thinks that it will.
Updated by Victor Julien over 14 years ago
Does this mean the patch is correct or not?
Updated by Will Metcalf over 14 years ago
It means the 002 patch is correct but In my opinion 003 is not.
Updated by Victor Julien over 14 years ago
- Status changed from Resolved to Closed
- % Done changed from 90 to 100
Ok, applied only 0002. Thanks guys.