Actions
Security #6441
closeddetect: heap use after free with http.request_header keyword
Git IDs:
bc422c17d6961f03f673f2999a949913e89fc2d0
Severity:
CRITICAL
Disclosure Date:
Description
Reproducer is with rules from #6415
alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"Host"; fast_pattern; classtype:web-application-attack; sid:41; rev:1;) alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"Cookie"; fast_pattern; classtype:web-application-attack; sid:42; rev:1;) alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"X-Qlik-User"; fast_pattern; classtype:web-application-attack; sid:43; rev:1;) alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"User-Agent"; fast_pattern; classtype:web-application-attack; sid:44; rev:1;) alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"Content-Length"; fast_pattern; classtype:web-application-attack; sid:45; rev:1;) alert http any any -> any any (msg:"Test Usage of http.request_header"; flow:established,to_server; http.request_header; content:"Transfer-Encoding"; fast_pattern; classtype:web-application-attack; sid:46; rev:1;)
Problem is that multi-buffer http.request_header sets up different InspectionBuffer all pointing to the same HttpHeaderBuffer which can get reallocated if a new header is bigger than 1024 cf HttpHeaderExpandBuffer
Files
Updated by Philippe Antoine 12 months ago
To assess severity, we need to check the scope : maybe this can be abused for other keywords than http.request_header (and response header)
Updated by Philippe Antoine 12 months ago
Stack trace is
==11146==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000010490 at pc 0x0001088b0630 bp 0x7ff7b7af71b0 sp 0x7ff7b7af71a8
READ of size 1 at 0x619000010490 thread T0
#0 0x1088b062f in BMScan util-spm-bm.c:459
#1 0x1085d35a8 in DetectEngineContentInspection detect-engine-content-inspection.c:294
#2 0x108645364 in DetectEngineInspectHttp1Header detect-http-header.c:709
#3 0x1085653af in DetectRun detect.c:160
#4 0x1085600b5 in Detect detect.c
#5 0x1086f14d7 in FlowWorker flow-worker.c:626
#6 0x10840ba7a in LLVMFuzzerTestOneInput fuzz_sigpcap.c:183
#7 0x108e54510 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:614
#8 0x108e3f144 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) FuzzerDriver.cpp:324
#9 0x108e44aa9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:859
#10 0x108e71482 in main FuzzerMain.cpp:20
#11 0x7ff80b7d33a5 in start+0x795 (dyld:x86_64+0xfffffffffff5c3a5)
0x619000010490 is located 16 bytes inside of 1024-byte region [0x619000010480,0x619000010880)
freed by thread T0 here:
#0 0x10a6fcf02 in realloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0xe0f02)
#1 0x108871578 in SCReallocFunc util-mem.c:46
#2 0x1086481c6 in HttpHeaderExpandBuffer detect-http-header-common.c:90
#3 0x1086479d7 in GetHttp1HeaderData detect-http-header.c:616
#4 0x108647441 in PrefilterTxHttp1Header detect-http-header.c:655
#5 0x10860250b in DetectRunPrefilterTx detect-engine-prefilter.c:121
#6 0x108563e4b in DetectRun detect.c:160
#7 0x1085600b5 in Detect detect.c
#8 0x1086f14d7 in FlowWorker flow-worker.c:626
#9 0x10840ba7a in LLVMFuzzerTestOneInput fuzz_sigpcap.c:183
#10 0x108e54510 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:614
#11 0x108e3f144 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) FuzzerDriver.cpp:324
#12 0x108e44aa9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:859
#13 0x108e71482 in main FuzzerMain.cpp:20
#14 0x7ff80b7d33a5 in start+0x795 (dyld:x86_64+0xfffffffffff5c3a5)
previously allocated by thread T0 here:
#0 0x10a6fcf02 in realloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0xe0f02)
#1 0x108871578 in SCReallocFunc util-mem.c:46
#2 0x108647fe6 in HttpHeaderThreadDataInit detect-http-header-common.c:69
#3 0x1085c824c in ThreadCtxDoInit detect-engine.c:3282
#4 0x1085c909a in DetectEngineThreadCtxInitForReload detect-engine.c:3398
#5 0x10840b66f in LLVMFuzzerTestOneInput fuzz_sigpcap.c:139
#6 0x108e54510 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:614
#7 0x108e3f144 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) FuzzerDriver.cpp:324
#8 0x108e44aa9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:859
Updated by Victor Julien 12 months ago
- Target version changed from 7.0.3 to 8.0.0-beta1
Updated by Victor Julien 10 months ago
- Severity changed from MODERATE to CRITICAL
Can be triggered by evil client or evil server if rules with http.request_header or http.response_header are present, so CRITICAL.
Updated by Philippe Antoine 9 months ago
- Related to Bug #6415: http.header, http.header.raw and http.request_header buffers not populated when malformed header value exists added
Updated by Victor Julien 9 months ago
- Status changed from In Review to Resolved
- CVE set to 2024-23839
Updated by Victor Julien 9 months ago
- Related to Bug #6736: http.request_header and http.response_header behavior with HTTP1 traffic added
Updated by Philippe Antoine 9 months ago
- Status changed from Resolved to Closed
- Git IDs updated (diff)
Updated by Philippe Antoine 9 months ago
- Related to Bug #6483: http.request_headers - odd behavior with multiple signtures added
Actions