Project

General

Profile

Actions

Bug #205

closed

Segv inside of DetectHttpMethodMatch() when processing the attached rule/pcap.

Added by Will Metcalf almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Setting priority as high, currently all fuzzers blow up here...

ulimit -c unlimited; src/suricata -c suricata.yaml -r iCTF200725.httpparseerror.pcap -l ./ -s blah.rules

#0 0x0000000000480e78 in DetectHttpMethodMatch (t=0x19924e0, det_ctx=0x7fa774000fe0, f=0x167aea0, flags=64 '', state=0x7fa77400a3d0, s=0x1c6d710, sm=0x1c6dd90) at detect-http-method.c:107
107 idx < list_size(hs->connp->conn->transactions); idx++)
(gdb) bt full
#0 0x0000000000480e78 in DetectHttpMethodMatch (t=0x19924e0, det_ctx=0x7fa774000fe0, f=0x167aea0, flags=64 '
', state=0x7fa77400a3d0, s=0x1c6d710, sm=0x1c6dd90) at detect-http-method.c:107
idx = 0
data = 0x1c6e2e0
hs = 0x7fa77400a3d0
tx = 0x0
ret = 0
#1 0x000000000044df27 in DeStateDetectStartDetection (tv=0x19924e0, de_ctx=0x19882a0, det_ctx=0x7fa774000fe0, s=0x1c6d710, f=0x167aea0, flags=64 '', alstate=0x7fa77400a3d0, alproto=1) at detect-engine-state.c:348
sm = 0x1c6dd90
match = 0
r = 0
umatch = 0 '\000'
uinspect = 0 '\000'
dmatch = 0 '\000'
dinspect = 0 '\000'
appinspect = 0 '\000'
appmatch = 0 '\000'
#2 0x0000000000427e6c in SigMatchSignatures (th_v=0x19924e0, de_ctx=0x19882a0, det_ctx=0x7fa774000fe0, p=0x12cd170) at detect.c:939
match = 0
fmatch = 0
s = 0x1c6d710
sm = 0x0
idx = 0
alproto = 1
alstate = 0x7fa77400a3d0
flags = 64 '
'
cnt = 0
sgh = 0x0
use_flow_sgh = 0 '\000'
smsg = 0x0
no_store_flow_sgh = 0 '\000'
de_state_start = 1 '\001'
#3 0x0000000000428480 in Detect (tv=0x19924e0, p=0x12cd170, data=0x7fa774000fe0, pq=0x19925f0, postpq=0x1992668) at detect.c:1125
det_ctx = 0x7fa774000fe0
de_ctx = 0x19882a0
r = 0
#4 0x00000000004b6784 in TmThreadsSlot1 (td=0x19924e0) at tm-threads.c:371
tv = 0x19924e0
s = 0x19925c0
p = 0x12cd170
run = 1 '\001'
r = TM_ECODE_OK
#5 0x00007fa7860099ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
res = <value optimized out>
pd = 0x7fa782c92710
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140357430486800, -5705563091241878573, 0, 0, 0, 0, 5737235229168548819, 5737243531514264531}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 0}}}
not_first_call = <value optimized out>
robust = <value optimized out>
freesize = <value optimized out>
__PRETTY_FUNCTION
= "start_thread"
#6 0x00007fa7859186fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#7 0x0000000000000000 in ?? ()
No symbol table info available.


Files

iCTF200725.httpparseerror.pcap (1.84 KB) iCTF200725.httpparseerror.pcap http session error pcap Will Metcalf, 07/07/2010 09:57 AM
blah.rules (92 Bytes) blah.rules test rule for http method. Will Metcalf, 07/07/2010 09:57 AM
one.pcap (953 Bytes) one.pcap Victor Julien, 07/07/2010 11:33 AM
Actions #1

Updated by Victor Julien almost 14 years ago

  • Assignee changed from OISF Dev to Pablo Rincon
Actions #2

Updated by Victor Julien almost 14 years ago

It appears that due to recent stream reassembly changes, in this pcap the toclient part of the stream is processed first, causing an error in the htp module. This leaves in the HtpState without a connp. The Http Method match function doesn't check this. Adding such a check won't hurt, but it's not the solution. We need to make sure the toclient part of the stream is not processed first.

Attached a new pcap with just one stream.

Actions #3

Updated by Victor Julien almost 14 years ago

In stream-tcp-reassembly.c, StreamTcpReassembleHandleSegmentUpdateACK I added some code to force reassembly if the protocol isn't (yet) detected, but the session is shutting down already. I think we can solve the issue here by making sure that we do this in the to_server direction first.

So maybe adding a flag to the tcp session to indicate toserver traffic has been reassembled, and checking for that before we force the reassembly, will likely resolve this issue.

Actions #4

Updated by Victor Julien almost 14 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Issue fixed in current master, commit 4c94a27b71e1aeefa1dc8b017d96f9082e4cd550.

Thanks Pablo!

Actions

Also available in: Atom PDF