Project

General

Profile

Actions

Bug #4624

closed

byte_jump with negative post_offset before start of buffer failure

Added by Jessie Leung over 2 years ago. Updated 5 months ago.

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

Description

Quoting documentation for post_offset:
[post_offset] <value> After the jump operation has been performed, it will jump an additional number of bytes specified by <value>
post_offset works with negative values to jump the pointer back this value, and proceeding patterns can continue matching. It's useful as a negative distance value for relative PCRE following it in my use case.

For this bug, when the negative value sends the pointer back beyond the start of the buffer, the signature is failed. This isn't consistent with other negative jump values eg. a larger negative distance following content will still be able to match from the actual start of the buffer. This is what I expected from the post_offset.

To illustrate this with an example pcap [random_tcp.pcap]:

1. (success) Matching within the packet (bytes 5-8) and using byte_jump with post_offset -8 to move the pointer back to the start of the buffer. This is able to match.
drop tcp any any -> any any ( msg:"Test"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -8; pcre:"/\x4e\x53\x4c\x4f/R"; sid:1000001; )

2. (failure) The same patterns, but using a post_offset -10 (2 bytes before the start of the buffer) will fail.
drop tcp any any -> any any ( msg:"Test.2"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; pcre:"/\x4e\x53\x4c\x4f/R"; sid:1000002; )

3. (failure) Actually, even the inclusion of this larger post_offset itself is enough to fail the signature without any proceeding patterns.
drop tcp any any -> any any ( msg:"Test.3"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; sid:1000003; )

4. (success) A negative distance modifier for content is successful even if it goes beyond the start of the buffer.
drop tcp any any -> any any ( msg:"Test.4"; rev:1; content:"|0A 95 00 20|"; content:"|4e 53 4c 4f|"; distance:-10; sid:1000004; )

This is tested on 5.0.3.


Files

random_tcp.pcap (243 Bytes) random_tcp.pcap example capture of a single tcp packet Jessie Leung, 08/24/2021 10:23 PM

Subtasks 1 (0 open1 closed)

Bug #6377: byte_jump with negative post_offset before start of buffer failure (6.0.x backport)ClosedShivani BhardwajActions

Related issues 1 (0 open1 closed)

Related to Suricata - Bug #4623: byte_jump with negative post_offset value fails at the end of the bufferClosedJeff LucovskyActions
Actions #1

Updated by Philippe Antoine 9 months ago

Why do use pcre instead of content here ? (it looks fixed)
And if you can use content, why do not you start with the content appearing first ?

Actions #2

Updated by Jessie Leung 9 months ago

Philippe Antoine wrote in #note-1:

Why do use pcre instead of content here ? (it looks fixed)
And if you can use content, why do not you start with the content appearing first ?

The PCRE were kept simple for the sake of an example, but in some cases I genuinely needed PCRE to match non-static content while jumping back some distance after some fixed content is matched.

Actions #3

Updated by Victor Julien 9 months ago

  • Status changed from New to Assigned
  • Assignee set to Jeff Lucovsky
  • Target version set to 7.0.1

@Jeff Lucovsky lets also consider if this needs a backport.

Actions #4

Updated by Victor Julien 9 months ago

  • Related to Bug #4623: byte_jump with negative post_offset value fails at the end of the buffer added
Actions #5

Updated by Victor Julien 7 months ago

  • Target version changed from 7.0.1 to 7.0.2
Actions #6

Updated by Jeff Lucovsky 7 months ago

teajj Is it your expectation that a negative @post_offset will never move the pointer prior to the buffer?

Using your example, a value of -10 would be before the buffer whereas a value of -8 is at the buffer start. So, treat -10 as though it were -8?

Actions #7

Updated by Jessie Leung 7 months ago

Jeff Lucovsky wrote in #note-6:

teajj Is it your expectation that a negative @post_offset will never move the pointer prior to the buffer?

Using your example, a value of -10 would be before the buffer whereas a value of -8 is at the buffer start. So, treat -10 as though it were -8?

That's correct, I feel it should either be at the buffer start or at least it shouldn't fail the rest of the signature. It's been a while since I tested this, but referring to example 3)

3. (failure) Actually, even the inclusion of this larger negative post_offset itself is enough to fail the signature without any proceeding patterns.
drop tcp any any -> any any ( msg:"Test.3"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; sid:1000003; )

The signature doesn't trigger at all after making the jump without even trying to match anything after it, which is a weird behaviour.
It could be treated as a -10 still (so a distance/within in a following pattern has to take into account the extra -2 bytes anyway), or it could be treated as a -8 and always be at the buffer start.

If, say, we jump -10 and try to match PCRE with an anchor like ^ eg. byte_jump:0,0,relative,post_offset -10; pcre:"/^\x4e\x53\x4c\x4f/R";, and it's before the buffer, it may not be expected to work and that's fine. If treated as a -8 and at buffer start then it would work. Not sure which makes more sense but either seem like valid behaviour to me.

The only expectation is that we jumped -10 and we should still be able to search any patterns from that point regardless if we're in pre-start-of-buffer limbo, as long as we're not checking exactly there. So my original example of byte_jump:0,0,relative,post_offset -10; pcre:"/\x4e\x53\x4c\x4f/R"; should be able to trigger.

Actions #8

Updated by Jeff Lucovsky 7 months ago

  • Status changed from Assigned to In Review
Actions #9

Updated by Victor Julien 6 months ago

  • Status changed from In Review to Resolved
  • Label Needs backport to 6.0 added
Actions #10

Updated by OISF Ticketbot 6 months ago

  • Subtask #6377 added
Actions #11

Updated by OISF Ticketbot 6 months ago

  • Label deleted (Needs backport to 6.0)
Actions #12

Updated by Victor Julien 5 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF