Bug #158

byte_test + relative modifer doesn't work when previous keyword is byte_jump

Added by Will Metcalf almost 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:05/13/2010
Priority:NormalDue date:05/18/2010
Assignee:Gurvinder Singh% Done:

100%

Category:-Estimated time:2.50 hours
Target version:0.9.1

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

allworkandnoplayplain.pcap - All work and no play pcap for testing byte_jump + byte_test,relative (2.7 KB) Will Metcalf, 05/13/2010 12:19 PM

0002-support-setting-up-byte_test-relative-when-byte_jumo.patch Magnifier (4.02 KB) Gurvinder Singh, 05/15/2010 01:49 PM

0003-support-setting-up-byte_jump-relative-when-byte_test.patch Magnifier (1.99 KB) Gurvinder Singh, 05/15/2010 01:49 PM

History

#1 Updated by Gurvinder Singh almost 4 years ago

  • Assignee changed from OISF Dev to Gurvinder Singh

#2 Updated by Gurvinder Singh almost 4 years ago

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.

#3 Updated by Will Metcalf almost 4 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.

#4 Updated by Gurvinder Singh almost 4 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;)

#5 Updated by Will Metcalf almost 4 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.

#6 Updated by Victor Julien almost 4 years ago

Does this mean the patch is correct or not?

#7 Updated by Will Metcalf almost 4 years ago

It means the 002 patch is correct but In my opinion 003 is not.

#8 Updated by Victor Julien almost 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 90 to 100

Ok, applied only 0002. Thanks guys.

Also available in: Atom PDF