Project

General

Profile

Actions
Copy link

Bug #6105

closed

byte_jump does not allow variable name to be used consistently

Added by Jason Taylor 11 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Jeff Lucovsky
Target version:
7.0.0
Affected Versions:
Effort:
Difficulty:
Label:

Description

It doesn't appear that byte_jump allows the use of a variable name for the number of bytes but it is allowed for offset?

"The value in <var_name> can be used in any modifier that takes a number as an option and in the case of byte_test it can be used as a value."

alert tcp any any -> any any (msg:"byte_jump varname test sig"; flow:to_server,established; content:"|00 00 00|"; byte_extract:1,0,rpkt_len,relative; byte_jump:rpkt_len,0,relative; isdataat:!1,relative; classtype:bad-unknown; sid:1; rev:1;)

[50474 - Suricata-Main] 2023-05-30 21:01:43 Error: detect-bytejump: Malformed number of bytes: rpkt_len,0,relative
[50474 - Suricata-Main] 2023-05-30 21:01:43 Debug: detect-parse: "byte_jump" failed to setup
[50474 - Suricata-Main] 2023-05-30 21:01:43 Error: detect: error parsing signature "alert tcp any any -> any any (msg:"byte_jump varname test sig 1"; flow:to_server,established; content:"|00 00 00|"; byte_extract:1,0,rpkt_len,relative; byte_jump:rpkt_len,0,relative; isdataat:!1,relative; classtype:bad-unknown; sid:1; rev:1;)" from file /home/jt/rules/test.rules at line 1

the following sig does load
alert tcp any any -> any any (msg:"byte_jump varname test sig 2"; flow:to_server,established; content:"|00 00 00|"; byte_extract:1,0,rpkt_len,relative; byte_jump:0,rpkt_len,relative; isdataat:!1,relative; classtype:bad-unknown; sid:2; rev:1;)

[50549 - Suricata-Main] 2023-05-30 21:05:44 Debug: detect: signature 2 loaded
[50549 - Suricata-Main] 2023-05-30 21:05:44 Info: detect: 1 rule files processed. 1 rules successfully loaded, 1 rules failed

[50579 - W#01] 2023-05-30 21:06:07 Debug: detect-byte-extract: extracted value is 5
[50579 - W#01] 2023-05-30 21:06:07 Debug: detect: [BE] Fetched value for index 0: 5
[50582 - FR#01] 2023-05-30 21:06:07 Debug: flow-manager: woke up...
[50579 - W#01] 2023-05-30 21:06:07 Debug: detect: Entering ... >>
[50579 - W#01] 2023-05-30 21:06:07 Debug: detect: byte_jump offset is: 5
[50579 - W#01] 2023-05-30 21:06:07 Debug: detect-bytejump: Entering ... >>

I added some additional logging to my setup to get the debug information for byte_jump values but we can see the byte_jump offset is 5 for the second signature which is our rpkt_len value from the byte extract in the attached pcap.

Files

240d9c750e7c942.pcap (527 Bytes) 240d9c750e7c942.pcap Jason Taylor, 05/30/2023 09:11 PM

Related issues 1 (0 open — 1 closed)

Copied to Suricata - Feature #6144: byte_test: allow variable name for nbytesClosedJeff LucovskyActions
Actions
Copy link
 #1

Updated by Jason Taylor 11 months ago

  • Subject changed from byte_jump does not allow variable name to be used to byte_jump does not allow variable name to be used consistently
Actions
Copy link
 #2

Updated by Victor Julien 11 months ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Jeff Lucovsky
  • Priority changed from Normal to Low
  • Target version changed from TBD to 7.0.0-rc2

Jeff can you have a look? Setting as low for rc2, will retarget to 7.0.0 or 7.0.1 if we can't make it in time.

Also needs to be considered for backport.

Actions
Copy link
 #3

Updated by Jeff Lucovsky 11 months ago

  • Status changed from Assigned to In Progress
Actions
Copy link
 #4

Updated by Jeff Lucovsky 11 months ago

Yes, I'll investigate. I can confirm that only the offset can (currently) be a variable name or scalar value.

Note that none of the other byte keywords accept a variable name in place of the byte count. The Snort documentation states that offset may be a variable but not bytes.

@Victor Julien - we can deviate from Snort compatibility for the byte value -- is that the direction we want to move?

Actions
Copy link
 #5

Updated by Jeff Lucovsky 11 months ago

@Jason Taylor Are you able to validate the changes in https://github.com/OISF/suricata/pull/9006 that add the capability?

Actions
Copy link
 #6

Updated by Jason Taylor 11 months ago

Jeff Lucovsky wrote in #note-5:

@Jason Taylor Are you able to validate the changes in https://github.com/OISF/suricata/pull/9006 that add the capability?

I can, I will take a look first thing next week. Thanks Jeff!

JT

Actions
Copy link
 #7

Updated by Jason Taylor 11 months ago

Jason Taylor wrote in #note-6:

Jeff Lucovsky wrote in #note-5:

@Jason Taylor Are you able to validate the changes in https://github.com/OISF/suricata/pull/9006 that add the capability?

I can, I will take a look first thing next week. Thanks Jeff!

JT

suricata -V
This is Suricata version 7.0.0-rc2-dev (0ca27d89c 2023-06-10)

Ran the PR with the rules and pcap attached. The sid:1; sig from this ticket loads and from the logs appears to have the right value. Log snippet:

[31020 - FR#01] 2023-06-12 14:14:39 Debug: threads: ts->tv_sec 1685024796
[31020 - FR#01] 2023-06-12 14:14:39 Debug: time: time we got is 1685024796 sec, 287759 usec
[31020 - FR#01] 2023-06-12 14:14:39 Debug: flow-manager: ts 1685024796
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: Entering ... >>
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: inspecting content 0 buffer_len 10
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: offset 0, prev_offset 0
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: offset 0, depth 10
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: sbuffer_len 10 depth: 10, buffer_len: 10
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: found 0x7f65707a4fb0 cd negated false
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: content 0 matched at offset 3
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: content 0
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: Entering ... >>
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-byte-extract: relative, working with det_ctx->buffer_offset 3, data->offset 0
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-byte-extract: extracted value is 5
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: [BE] Fetched value for index 0: 5
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: Entering ... >>
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: Entering ... >>
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: VAL: (223925895201 x 1) + 5 + 0
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: NEWVAL: ptr 0x7f65707a4fb4 + 223925895210
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: Jump location (223925895210) is not within payload (10)
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: Returning: 0 ... <<
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: Returning: 0 ... <<
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: Returning: 0 ... <<
[31020 - FR#01] 2023-06-12 14:14:39 Debug: flow-manager: woke up...
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: no match for 'next sm'
[31018 - W#01] 2023-06-12 14:14:39 Debug: detect: 'next sm' depends on me 0x563139ee9a20, lets see what we can do (flags 1441792)

This may be a separate thing but I am curious where the byte jump location value is coming from in this log snippet:

[31018 - W#01] 2023-06-12 14:14:39 Debug: detect-bytejump: Jump location (223925895210) is not within payload (10)

Actions
Copy link
 #8

Updated by Jeff Lucovsky 11 months ago

The PCAP data is

0000000 c3d4 a1b2 0002 0004 0000 0000 0000 0000
0000010 ffff 0000 0001 0000 701c 646f 640f 0004
0000020 0036 0000 0036 0000 a6a7 4162 365d 705e
0000030 b141 05d7 0008 0045 2800 0100 0000 0640
0000040 d799 a8c0 1a3e 10ac 2536 293f e748 0000
0000050 0a00 0000 0000 0250 0020 d026 0000 701c
0000060 646f 6723 0004 0036 0000 0036 0000 b605
0000070 4b77 19b7 10f3 f335 2cb2 0008 0045 2800
0000080 0100 0000 0640 d799 10ac 2536 a8c0 1a3e
0000090 e748 293f 0000 6400 0000 0b00 1250 0020
00000a0 5b26 0000 701c 646f 6a27 0004 0036 0000
00000b0 0036 0000 ad23 ec32 301c 195c 2248 514b
00000c0 0008 0045 2800 0100 0000 0640 d799 a8c0
00000d0 1a3e 10ac 2536 293f e748 0000 0b00 0000
00000e0 6500 1050 0020 5c26 0000 701c 646f 6e40
00000f0 0004 0040 0000 0040 0000 148f 6c74 822f
0000100 48a0 d3b6 6be3 0008 0045 3200 0100 0000
0000110 0640 cd99 a8c0 1a3e 10ac 2536 293f e748
0000120 0000 0b00 0000 6500 1850 0020 17cb 0000
0000130 0000 0500 2334 0006 0a21 701c 646f 70ee
0000140 0004 0036 0000 0036 0000 3fb7 2726 17ac
0000150 8dd7 0264 42a0 0008 0045 2800 0100 0000
0000160 0640 d799 10ac 2536 a8c0 1a3e e748 293f
0000170 0000 6500 0000 1500 1050 0020 5226 0000
0000180 701c 646f 7483 0004 0039 0000 0039 0000
0000190 78e3 2ccb 03a8 aa7d 0340 c4eb 0008 0045
00001a0 2b00 0100 0000 0640 d499 10ac 2536 a8c0
00001b0 1a3e e748 293f 0000 6500 0000 1500 1850
00001c0 0020 4725 0000 0000 1c01 6f70 5664 0477
00001d0 3600 0000 3600 0000 8000 96c0 c9b2 6660
00001e0 e686 e44b 0833 4500 0000 0028 0001 4000
00001f0 9906 c0d7 3ea8 ac1a 3610 3f25 4829 00e7
0000200 0000 0015 0000 5068 2010 2600 004f 0000
000020f

The jump offset is set to 0x342306002a which ix 0x3423060021 + 5 (from byte_extract) and 4 (due to relative).

Actions
Copy link
 #9

Updated by Jeff Lucovsky 11 months ago

  • Copied to Feature #6144: byte_test: allow variable name for nbytes added
Actions
Copy link
 #10

Updated by Victor Julien 10 months ago

  • Target version changed from 7.0.0-rc2 to 7.0.0
Actions
Copy link
 #11

Updated by Jeff Lucovsky 10 months ago

  • Status changed from In Progress to In Review
Actions
Copy link
 #12

Updated by Jeff Lucovsky 10 months ago

@Jason Taylor Can you take another look at the PR and the associated suricata-verify PR?

I've verified that the logic is using the proper value for the variable substitution.

Actions
Copy link
 #13

Updated by Victor Julien 10 months ago

  • Status changed from In Review to Closed
  • Priority changed from Low to Normal
Actions
Copy link

Also available in: Atom PDF