detect/http: fix progress for headers keywords #11977
Conversation
Ticket: 7326 Having a lower progress than the right one, made prefilter bail out too early, not having found a buffer in the multi-buffer that mathed the prefilter. Hence, we got false negatives, if http.request_header or http.response_header was used as fast pattern, and if the request or response came in multiple packets, and the first of these packets did not have enough data (like only http request line), and the next packets did have the matching data.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #11977 +/- ##
==========================================
- Coverage 82.77% 82.66% -0.12%
==========================================
Files 910 910
Lines 249016 249016
==========================================
- Hits 206134 205848 -286
- Misses 42882 43168 +286
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
WARNING:
Pipeline 23121 |
|
Hi @catenacyber ! Could you please tell what does "right one" mean in your commit message "Having a lower progress than the right one.."? |
Ok will do The "right one" is the progress where you can actually get occurrences of the multi buffer If you register a multi-buffer with a progress lower than the one where you actually get these, and you have some packets that reach this lower progress, but not the values of the multi-buffer (for example the HTTP request line, but not the http headers), prefilter will see that there are 0 values for the multi-buffer and conclude that this signature will never match for this transaction... Does that explanation make things clearer ? |
|
Next in #12056 |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7326
Describe changes:
SV_BRANCH=OISF/suricata-verify#2094
Should we have the generic fix of
DetectAppLayerMultiRegisterusing only one tx progress ?#11968 with better commit message