Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detect/sip: add sticky buffers to match headers v4 #11330

Closed
wants to merge 12 commits into from

Conversation

glongo
Copy link
Contributor

@glongo glongo commented Jun 20, 2024

Make sure these boxes are signed before submitting your Pull Request -- thank you.

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/6374

Describe changes:

  • Store multiple values for a single header
  • Header name in compact form is extended into long form

SV_BRANCH=OISF/suricata-verify#1926

glongo added 12 commits June 19, 2024 21:21
A stub file has been added to implement the sticky buffers for SIP headers.

Ticket OISF#6374
According to RFC 3261, a single header can be repeated one or more times,
and its name can also be specified using the 'compact form.'

This patch updates the hashmap used for storing headers to accommodate multiple
values instead of just one.

Additionally, if a header name is defined in the compact form, it is expanded
into its long form (i.e., the standard name).

This conversion simplifies the logic for matching a given header
and ensures 1:1 parity with keywords.

Ticket OISF#6374
To match on response SIP headers, those headers must be stored.

Ticket OISF#6374
Copy link

codecov bot commented Jun 20, 2024

Codecov Report

Attention: Patch coverage is 95.83333% with 6 lines in your changes missing coverage. Please review.

Project coverage is 82.41%. Comparing base (6256391) to head (5334c3f).
Report is 115 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11330      +/-   ##
==========================================
- Coverage   82.41%   82.41%   -0.01%     
==========================================
  Files         934      942       +8     
  Lines      247239   247376     +137     
==========================================
+ Hits       203773   203875     +102     
- Misses      43466    43501      +35     
Flag Coverage Δ
fuzzcorpus 60.22% <57.04%> (-0.02%) ⬇️
livemode 18.77% <41.54%> (+0.02%) ⬆️
pcap 43.75% <57.04%> (-0.04%) ⬇️
suricata-verify 61.40% <95.77%> (+0.04%) ⬆️
unittests 59.31% <57.63%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

@catenacyber
Copy link
Contributor

Thanks Giuseppe, quick remark : you can now have this in pure rust
cf #11316 for instance

@glongo
Copy link
Contributor Author

glongo commented Jun 20, 2024

Thanks Giuseppe, quick remark : you can now have this in pure rust cf #11316 for instance

I saw your commit about rust keywords merged but I have a question:
Can multi-buffer keywords already be written in Rust?

@catenacyber
Copy link
Contributor

Thanks Giuseppe, quick remark : you can now have this in pure rust cf #11316 for instance

I saw your commit about rust keywords merged but I have a question: Can multi-buffer keywords already be written in Rust?

I am doing it in #11316, this requires 7266b69

@catenacyber catenacyber added the needs rebase Needs rebase to master label Jul 13, 2024
Copy link
Contributor

@catenacyber catenacyber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work :-)

This PR needs a rebase

  • CI : 🟢
  • Code : checking now
  • Commits segmentation : I would squash some together
  • Commit messages : ok for me
  • Git ID set : looks fine for me
  • CLA : you already contributed
  • Doc update : looks fine
  • Redmine ticket : ok
  • Rustfmt : ok
  • Tests : SV ok
  • Dependencies added: none


void RegisterSipHeadersVia(void)
{
DetectSipHeadersRegisterStub();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can do them in rust now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I wrong, or has your PR for multibuffer keywords in rust not been merged yet?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been merged today :-)

@@ -97,6 +97,22 @@ fn is_header_value(b: u8) -> bool {
is_alphanumeric(b) || is_token_char(b) || b"\"#$&(),/;:<=>?@[]{}()^|~\\\t\n\r ".contains(&b)
}

fn expand_header_name(h: &str) -> &str {
match h {
"i" => "Call-ID",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we detect if some header uses the short or long form ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why should we detect that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To get the most expressivity.
I do no say we should do that, I just asked if we can.

I guess this deserves some mention in the docs., like

This keyword matches on the From field that can be present in SIP headers.
It matches both short and regular form, and these forms cannot be distinguished by this keyword.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand what you mean. If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.
If this is what you are referring to, it has already been implemented.
If not, I'm unclear on what you mean by 'detecting which form is used by a header.'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant 2 things :

If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.

  1. This should be in the docs

  2. And the doc should also mention that there is only the normalized form, not the raw one (as we can have for http uri for instance where there are 2 keywords)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant 2 things :

If a header uses the short form, it is 'expanded' ( converted to the long form) to enable matching in both cases with its related sticky buffer.

1. This should be in the docs

2. And the doc should also mention that there is only the normalized form, not the raw one (as we can have for http uri for instance where there are 2 keywords)

+1

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only have a nit comment for the copyright year change in sip/detect.rs, but do agree with Philippe's comment that we should mention in the docs about the headers being normalized :)

@@ -1,4 +1,4 @@
/* Copyright (C) 2019 Open Information Security Foundation
/* Copyright (C) 2024 Open Information Security Foundation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: when updating copyright years, we add the current year beside the initial one:

Suggested change
/* Copyright (C) 2024 Open Information Security Foundation
/* Copyright (C) 2019-2024 Open Information Security Foundation

@glongo
Copy link
Contributor Author

glongo commented Aug 10, 2024

Replaced with #11620

@glongo glongo closed this Aug 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs rebase Needs rebase to master
Development

Successfully merging this pull request may close these issues.

3 participants