Bug #407
closed
Added by Giovanni Tedaldi almost 13 years ago.
Updated over 12 years ago.
Description
I'm making some tests of suricata using ictf2010's traffic dumps.
I use tcpreplay to replicate pcap files on the interface suricata's listening.
The problem is that it crashes, every time. I'm using suricata 1.2.1.
Here's the backtrace:
#0 0x00007eff73976d06 in __memcpy_ssse3_back () from /lib/libc.so.6
#1 0x00000000004e1947 in ?? ()
#2 0x00000000004e2938 in ?? ()#3 0x000000000051770a in ?? ()
#4 0x00000000005152d6 in ?? ()
#5 0x0000000000515e8a in ?? ()
#6 0x00007eff74afd507 in hook_run_all () from /usr/lib/libhtp-0.2.so.1
#7 0x00007eff74b02eb4 in htp_connp_REQ_BODY_IDENTITY () from /usr/lib/libhtp-0.2.so.1
#8 0x00007eff74b03f21 in htp_connp_req_data () from /usr/lib/libhtp-0.2.so.1
#9 0x0000000000514a04 in ?? ()
#10 0x000000000050d2a1 in ?? ()
#11 0x000000000050f8ca in ?? ()
#12 0x00000000004ff883 in ?? ()
#13 0x0000000000500574 in ?? ()
#14 0x0000000000501e6e in ?? ()
#15 0x00000000004f9cad in ?? ()
#16 0x00000000004fcb2d in ?? ()
#17 0x00000000004fe1b6 in ?? ()
#18 0x00000000004e3a75 in ?? ()
#19 0x00000000004e5d06 in ?? ()
#20 0x00007eff7406be7a in start_thread () from /lib/libpthread.so.0
#21 0x00007eff7392cb7d in clone () from /lib/libc.so.6
#22 0x0000000000000000 in ?? ()
Hi ,
Would you please provide the following:
1. pcap - or at least a link towards the pcap, if available (the smaller the better, as long as we can reproduce the issue)
2. suricata.yaml
3. The way you use/start suricata (like, do you use pfring,nfqueue....)
4. I assume we are talking about - http://ictf.cs.ucsb.edu/index.php - correct ?
Thank you
Ok,
When you did tcprewrite L2 - what exactly did you rewrite - vlan, src/dst MAC addresses ..?
Thanks
I've used: tcprewrite --dlt=enet --enet-dmac=00:12:13:14:15:16,00:22:33:44:55:66 --enet-smac=00:12:13:14:15:16,00:22:33:44:55:66 -i $i -o $o.pcap
Since the original dlt is raw and it was giving me troubles.
Hi Giovanni,
I will try to reproduce the issue and get back to you.
Thanks
- Status changed from New to Assigned
- Assignee set to Peter Manev
- Target version set to 1.3beta1
- Estimated time set to 4.00 h
I've compiled suricata with --enable-debug and, this time, I also remebered to add the option !strip.
Here's the backtrace:
#0 0x00007f0eb6459be4 in __memcpy_ssse3_back () from /lib/libc.so.6
#1 0x0000000000525cb7 in FileDataAlloc ()
#2 0x00000000005272c4 in FileOpenFile ()
#3 0x000000000058ee5c in HTPFileOpen ()
#4 0x000000000058a0a0 in HtpRequestBodyHandleMultipart ()
#5 0x000000000058bddb in HTPCallbackRequestBodyData ()
#6 0x00007f0eb75e0507 in hook_run_all (hook=0x52b0af0, data=0x7f0eb49cd710) at hooks.c:136
#7 0x00007f0eb75e5eb4 in htp_connp_REQ_BODY_IDENTITY (connp=0x7f0e2290c3d0) at htp_request.c:239
#8 0x00007f0eb75e6f21 in htp_connp_req_data (connp=0x7f0e2290c3d0, timestamp=<optimized out>, data=<optimized out>, len=<optimized out>) at htp_request.c:839
#9 0x00000000005885cd in HTPHandleRequestData ()
#10 0x000000000057a882 in AppLayerDoParse ()
#11 0x000000000057f852 in AppLayerParse ()
#12 0x000000000057790f in AppLayerHandleTCPData ()
#13 0x0000000000560ed1 in StreamTcpReassembleAppLayer.isra.7 ()
#14 0x0000000000562afd in StreamTcpReassembleHandleSegmentUpdateACK ()
#15 0x000000000056830f in StreamTcpReassembleHandleSegment ()
#16 0x000000000054d661 in StreamTcpPacketStateEstablished ()
#17 0x000000000055952c in StreamTcpPacket ()
#18 0x000000000055b128 in StreamTcp ()
#19 0x0000000000529655 in TmThreadsSlotVarRun ()
#20 0x000000000052c2b3 in TmThreadsSlotVar ()
#21 0x00007f0eb6b4ee7a in start_thread () from /lib/libpthread.so.0
#22 0x00007f0eb640fb7d in clone () from /lib/libc.so.6
#23 0x0000000000000000 in ?? ()
I hope it helps.
Hi,
Any particualr pcap number that you have the crush on? - have you noticed ?
thanks
I've made a few tests.
It seems to be 6.pcap, the original name (the one it has before tcprewriting) should be ictf2010.pcap6
Using: "sudo tcpreplay -t -L 369350 -i vmnet1 6.pcap" makes suricata crash, while: "sudo tcpreplay -t -L 369300 -i vmnet1 6.pcap" don't.
Although using only those 50 packets doesn't crash suricata, so I guess it's a mix of speed and packets, a sort of letal mix.
Hey Giovani,
The issue has been fixed in the latest master.
- Status changed from Assigned to Resolved
- Status changed from Resolved to Closed
Also available in: Atom
PDF