Bug #6108
closed
http: leading gap in request data leads to invalid next request
Added by Victor Julien over 1 year ago.
Updated 3 months ago.
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
Do you have a pcap ready ?
- Target version changed from TBD to 7.0.0
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
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)
So, answer was missing --set vlan.use-for-tracking=false
Here is a pcap without vlan issues
- Status changed from Assigned to In Review
- Target version changed from 7.0.0 to 7.0.1
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.
- Target version changed from 7.0.1 to 7.0.2
- Target version changed from 7.0.2 to TBD
- 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
- Status changed from In Review to Rejected
Closing as explained above
Also available in: Atom
PDF