Bug #6108
closedhttp: leading gap in request data leads to invalid next request
Description
If there is a leading gap, the next request can get affected. E.g.
[ gap masking request line etc ]xxxxxPOST <rest of request>
In this case the method is parsed as
xxxxxPOST.
The parser knows if there is a leading GAP, so we should probably look for the start of the next request using a scan with the patterns used by the protocol detection.
Files
Updated by Philippe Antoine over 1 year ago
- Target version changed from TBD to 7.0.0
Updated by Philippe Antoine over 1 year ago
So, I notice that libhtp returns HTP_STREAM_CLOSED on leading gap in request, but Suricata only handles HTP_STREAM_ERROR and otherwise defaults to ok
Updated by Philippe Antoine over 1 year ago
There also seems to be a bug in tcp reassembly : htp_connp_req_data receives
- a gap of 1460 bytes
- data with 1460
- a gap of 177 bytes !!! (we have the data)
Updated by Philippe Antoine over 1 year ago
So, answer was missing --set vlan.use-for-tracking=false
Updated by Philippe Antoine over 1 year ago
Here is a pcap without vlan issues
Updated by Philippe Antoine over 1 year ago
- Status changed from Assigned to In Review
https://github.com/OISF/libhtp/pull/394 cleans this up a bit (maybe too much)
Updated by Philippe Antoine over 1 year ago
- Related to Task #6157: libhtp 0.5.45 added
Updated by Victor Julien over 1 year ago
- Target version changed from 7.0.0 to 7.0.1
Updated by Victor Julien over 1 year ago
- Related to deleted (Task #6157: libhtp 0.5.45)
Updated by Victor Julien over 1 year ago
- Related to Task #6209: libhtp 0.5.46 added
Updated by Philippe Antoine over 1 year ago
Status : issue mas misled in the sense that the pcap was supposed to be run with --set vlan.use-for-tracking=false
Now, is should have been unsupported to have leading gaps for HTTP1
But there was a misunderstanding between libhtp returning HTP_STREAM_CLOSED and Suricata matching it as not HTP_STREAM_ERROR
The libhtp PR cleans that a bit.
I wonder if we want it at all, or if we want to push back the target version.
Updated by Victor Julien over 1 year ago
- Target version changed from 7.0.1 to 7.0.2
Updated by Philippe Antoine over 1 year ago
- Target version changed from 7.0.2 to TBD
Updated by Philippe Antoine about 1 year ago
Updated by Philippe Antoine 12 months ago
- Assignee changed from Philippe Antoine to OISF Dev
I think we should close this issue, and open a new one if necessary with a clean history
Updated by Philippe Antoine 4 months ago
- Status changed from In Review to Rejected
Closing as explained above