Dcerpc incomplete 5699/v13 #12219
Dcerpc incomplete 5699/v13 #12219
Conversation
TCP data can be presented to the protocol parser in any way e.g. one byte at a time, single complete PDU, fragmented PDU, multiple PDUs at once. A limit of 1MB can be easily reached in some of such scenarios. Remove the check that rejects data that is more than 1MB.
to make it available for logging.
Instead of own internal mechanism of buffering in case of fragmented data, use AppLayerResult::incomplete API to let the AppLayer Parser take care of it. This makes the memory use more efficient. Remove any unneeded variables and code with the introduction of this API. Ticket 5699
With the introduction of AppLayerResult::incomplete API, fragmented data is no longer handled fully in the dcerpc code. Given that these code paths are already covered by the following s-v tests, these tests can now be safely removed. - dce-gap-handling - dcerpc-dce-iface-* Ticket 5699
- remove unneeded variables - remove unnecessary tracking of bytes in state - modify calculations as indicated by failing tests
as it is now covered by the suricata-verify test dcerpc-request-http-response.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #12219 +/- ##
==========================================
- Coverage 83.18% 83.14% -0.04%
==========================================
Files 912 912
Lines 257169 256787 -382
==========================================
- Hits 213914 213505 -409
- Misses 43255 43282 +27
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
WARNING:
Pipeline 23666 |
|
Do you have an explanation for the stat difference yet (#12025 (comment)) |
Yes. Upon analysis of pcaps, I found that my guess (intention reflected in #12227) was indeed correct. The more flows are because we no longer return error from the parser (in which case the flow counter is not incremented) in case the input buffer exceeds 1MB so now even the bigger flows are accepted by the parser. Why does then the PR #12227 have the same stat difference? Because I messed up the rebase and ultimately did remove the code that rejects input > 1MB https://github.com/OISF/suricata/pull/12227/files#diff-bb348f48dcbb4845f97a114f74772ee4849098c3254221826e5e0a61cbe35830L954 🤦🏽♀️ so 12227 is basically the same as this one. |
Link to redmine ticket: https://redmine.openinfosecfoundation.org/issues/5699
Previous PR: #12025
SV_BRANCH=OISF/suricata-verify#2160
Changes since v12: