Project

General

Profile

Actions
Copy link

Security #5921

closed

http1: configurable limit for maximum number of live transactions per flow

Added by Philippe Antoine almost 2 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Philippe Antoine
Target version:
8.0.0-beta1
Affected Versions:
Label:
CVE:
2024-23836
Git IDs:

8f63a8f3bffbbaf8fae4985ee5f974ab326b08c0
4175680a8a1c0dfaa491ee63d6e36c011d498473

Severity:
CRITICAL
Disclosure Date:
12/25/2023

Description

Kind of found by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55582

See also libhtp-rs oom

Subtasks 2 (0 open — 2 closed)

Security #6540: http1: configurable limit for maximum number of live transactions per flow (7.0.x backport)ClosedPhilippe AntoineActions
Security #6658: http1: configurable limit for maximum number of live transactions per flow (6.0.x backport)ClosedPhilippe AntoineActions

Related issues 2 (1 open — 1 closed)

Related to Suricata - Feature #2696: http: implement parser in rustIn ProgressPhilippe AntoineActions
Related to Suricata - Security #6299: mqtt pcap with anomalies takes too long to process because of app-layer-event detectionClosedPhilippe AntoineActions
Actions
Copy link
 #1

Updated by Philippe Antoine almost 2 years ago

Investigation shows that `http_state->conn->transactions` does not shrink as `VecDeque` when one transaction should get removed (the transaction is freed and replaced by NULL)

Need to think on this first...

Actions
Copy link
 #2

Updated by Philippe Antoine almost 2 years ago

Actions
Copy link
 #3

Updated by Philippe Antoine over 1 year ago

I thought I had a Suricata-only fix, but libhtp uses htp_list_get(connp->conn->transactions, connp->out_next_tx_index);
and tx->index = htp_list_size(tx->conn->transactions);

So, I may have a Suricata+libhtp fix...

Actions
Copy link
 #4

Updated by Philippe Antoine over 1 year ago

  • Status changed from New to In Review

POC Gitlab MRs

Actions
Copy link
 #5

Updated by Philippe Antoine over 1 year ago

  • Related to Security #6299: mqtt pcap with anomalies takes too long to process because of app-layer-event detection added
Actions
Copy link
 #6

Updated by Philippe Antoine over 1 year ago

  • Target version changed from TBD to 7.0.2
Actions
Copy link
 #7

Updated by Philippe Antoine over 1 year ago

  • Tracker changed from Bug to Security
  • Severity set to MODERATE
Actions
Copy link
 #8

Updated by Philippe Antoine about 1 year ago

So, I see 2 sub tasks here :
- do not have an ever growing list of HTTP1 transactions per flow
- configurable limit for maximum number of live HTTP1 transactions per flow
The current MR is for the first one

Another thing could be to have a configurable limit for maximum number of live transactions per flow whatever the app-layer protocol

The slowness of DetectRunTx when there are multiple live transactions per flow is to be tracked on #6299

See also https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62416&q=label%3AProj-suricata

Actions
Copy link
 #9

Updated by Victor Julien about 1 year ago

  • Target version changed from 7.0.2 to 7.0.3
Actions
Copy link
 #10

Updated by Victor Julien about 1 year ago

  • Target version changed from 7.0.3 to 8.0.0-beta1
  • Label Needs backport to 7.0 added
Actions
Copy link
 #11

Updated by OISF Ticketbot about 1 year ago

  • Subtask #6540 added
Actions
Copy link
 #12

Updated by OISF Ticketbot about 1 year ago

  • Label deleted (Needs backport to 7.0)
Actions
Copy link
 #13

Updated by Philippe Antoine 12 months ago

  • Disclosure Date set to 12/25/2023
Actions
Copy link
 #14

Updated by Victor Julien 12 months ago

  • Severity changed from MODERATE to CRITICAL

Easy to trigger, so CRITICAL.

Actions
Copy link
 #15

Updated by Victor Julien 12 months ago

  • Label Needs backport to 6.0 added
Actions
Copy link
 #16

Updated by OISF Ticketbot 12 months ago

  • Subtask #6658 added
Actions
Copy link
 #17

Updated by OISF Ticketbot 12 months ago

  • Label deleted (Needs backport to 6.0)
Actions
Copy link
 #18

Updated by Victor Julien 11 months ago

  • Status changed from In Review to Resolved
Actions
Copy link
 #19

Updated by Victor Julien 11 months ago

  • CVE set to 2024-23836
Actions
Copy link
 #20

Updated by Philippe Antoine 10 months ago

  • Status changed from Resolved to Closed
  • Git IDs updated (diff)
Actions
Copy link
 #21

Updated by Victor Julien 10 months ago

  • Private changed from Yes to No
Actions
Copy link

Also available in: Atom PDF