Project

General

Profile

Actions

Bug #6108

open

http: leading gap in request data leads to invalid next request

Added by Victor Julien 11 months ago. Updated 3 months ago.

Status:
In Review
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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

gap2.pcap (1.7 KB) gap2.pcap Philippe Antoine, 06/22/2023 08:19 AM

Related issues 1 (0 open1 closed)

Related to Suricata - Task #6209: libhtp 0.5.46ClosedVictor JulienActions
Actions #1

Updated by Philippe Antoine 11 months ago

Do you have a pcap ready ?

Actions #2

Updated by Philippe Antoine 10 months ago

  • Target version changed from TBD to 7.0.0
Actions #3

Updated by Philippe Antoine 10 months 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

Actions #4

Updated by Philippe Antoine 10 months 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)

Actions #5

Updated by Philippe Antoine 10 months ago

So, answer was missing --set vlan.use-for-tracking=false

Actions #6

Updated by Philippe Antoine 10 months ago

Here is a pcap without vlan issues

Actions #7

Updated by Philippe Antoine 10 months ago

  • Status changed from Assigned to In Review

https://github.com/OISF/libhtp/pull/394 cleans this up a bit (maybe too much)

Actions #8

Updated by Philippe Antoine 10 months ago

Actions #9

Updated by Victor Julien 9 months ago

  • Target version changed from 7.0.0 to 7.0.1
Actions #10

Updated by Victor Julien 9 months ago

Actions #11

Updated by Victor Julien 9 months ago

Actions #12

Updated by Philippe Antoine 9 months 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.

Actions #13

Updated by Victor Julien 7 months ago

  • Target version changed from 7.0.1 to 7.0.2
Actions #14

Updated by Philippe Antoine 7 months ago

  • Target version changed from 7.0.2 to TBD
Actions #16

Updated by Philippe Antoine 3 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

Actions

Also available in: Atom PDF