[Snort-devel] segfault in stream5

Russ Combs rcombs at ...402...
Wed Oct 5 10:12:25 EDT 2011


Thanks, we've got a bug filed and a fix for this issue will be out in a
future release.

In the mean time, you can prevent the bug by adding --enable-sourcefire to
your ./configure and rebuilding.

On Wed, Oct 5, 2011 at 12:35 AM, snort user <snort.user at ...2499...> wrote:

> Brett,
>
> Also, could you post your http inspect and unified2 configurations. It
> may be possible to work around this bug by tweaking the config
> options. Just a thought.
>
> cheers.
>
>
>
> On Wed, Oct 5, 2011 at 12:11 AM, snort user <snort.user at ...2499...> wrote:
> > Brett,
> >
> > It looks like there is a bug and as Joel had suggested you may want to
> > file a bug via the proper channel.
> >
> > In short, GetHttpGzipData is expecting Packet * as the first argument,
> > where as it is being passed ssnptr as the first argument.
> >
> > Details -
> >
> >> When the function crashes the ssnptr is invalid. In a different frame
> you will notice the correct ssnptr (0xf3e97f0)
> >
> > Specifically, focus on GetHttpGzipData. Here is how it gets called -
> >
> > GetHttpGzipData (data=0x5ea000005ea, buf=0x5, len=0x7fffd61d95e8,
> > type=0x7fffd61d95ec)
> >
> > and here is the actual function signature -
> >
> > int GetHttpGzipData(void *data, uint8_t **buf, uint32_t *len, uint32_t
> *type)
> >
> >
> > Notice how "ssnptr" is passed to GetHttpGzipData as first argument
> > when it is being used as Packet *.
> >
> >
> > void AlertExtraData(void *ssnptr, void *data, LogFunction *log_funcs,
> > uint16_t log_func_count, uint32_t event_id, uint32_t event_second)
> > {
> > <snip>
> >
> >    for(i=0; i< log_func_count; i++)
> >    {
> >        if((*(log_funcs[i]))(ssnptr, &write_buffer,&len,&type))
> > <snip>
> >
> >
> >
> > int GetHttpGzipData(void *data, uint8_t **buf, uint32_t *len, uint32_t
> *type)
> > {
> >    if(!IsGzipData((Packet *)data))
> >
> >
> >
> >
> > cheers. I hope that was helpful.
> >
> >
> >
> > On Tue, Oct 4, 2011 at 10:51 AM, Brett Edgar <brett.edgar at ...2499...>
> wrote:
> >> I did a grep.  That function is not called (by that name) anywhere
> >> else in the code.
> >>
> >> Here's the backtrace:
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> Stream5GetApplicationData (ssnptr=0x5ea000005ea, protocol=5) at
> >> spp_stream5.c:1368
> >> 1368    spp_stream5.c: No such file or directory.
> >>        in spp_stream5.c
> >> (gdb) bt
> >> #0  Stream5GetApplicationData (ssnptr=0x5ea000005ea, protocol=5) at
> >> spp_stream5.c:1368
> >> #1  0x000000000046c4d5 in GetHttpSessionData (p=<value optimized out>)
> >> at ./snort_httpinspect.h:163
> >> #2  IsGzipData (p=<value optimized out>) at snort_httpinspect.c:3846
> >> #3  0x000000000046c51a in GetHttpGzipData (data=0x5ea000005ea,
> >> buf=0x5, len=0x7fffd61d95e8, type=0x7fffd61d95ec)
> >>    at snort_httpinspect.c:3859
> >> #4  0x0000000000449bc2 in AlertExtraData (ssnptr=0xf3e97f0,
> >> data=<value optimized out>, log_funcs=<value optimized out>,
> >>    log_func_count=<value optimized out>, event_id=2707977984,
> >> event_second=4294967295) at spo_unified2.c:777
> >> #5  0x0000000000491adf in purge_alerts (tcpssn=<value optimized out>,
> >> talker=0x7fb5873e3160, listener=<value optimized out>,
> >>    tdb=<value optimized out>, p=0x7fffd61d99f0) at
> snort_stream5_tcp.c:3211
> >> #6  purge_to_seq (tcpssn=<value optimized out>, talker=0x7fb5873e3160,
> >> listener=<value optimized out>,
> >>    tdb=<value optimized out>, p=0x7fffd61d99f0) at
> snort_stream5_tcp.c:3304
> >> #7  CheckFlushPolicyOnAck (tcpssn=<value optimized out>,
> >> talker=0x7fb5873e3160, listener=<value optimized out>,
> >>    tdb=<value optimized out>, p=0x7fffd61d99f0) at
> snort_stream5_tcp.c:9106
> >> #8  0x000000000049598b in ProcessTcp (lwssn=0xf3e97f0,
> >> p=0x7fffd61d99f0, tdb=<value optimized out>,
> >> s5TcpPolicy=0x7fb57aaf3010)
> >>    at snort_stream5_tcp.c:8684
> >> #9  0x0000000000496178 in Stream5ProcessTcp (p=0x7fffd61d99f0,
> >> lwssn=0xf3e97f0, s5TcpPolicy=0x7fb57aaf3010, skey=0x7fffd61d9920)
> >>    at snort_stream5_tcp.c:5132
> >> #10 0x000000000047a369 in Stream5Process (p=0x7fffd61d99f0,
> >> context=<value optimized out>) at spp_stream5.c:1213
> >> #11 0x0000000000431b85 in Preprocess (p=0x7fffd61d99f0) at detect.c:170
> >> #12 0x0000000000426dee in ProcessPacket (user=<value optimized out>,
> >> pkthdr=0x7fffd61da760, pkt=<value optimized out>, ft=0x0)
> >>    at snort.c:1490
> >> #13 0x000000000042adfa in PacketCallback (user=0x0,
> >> pkthdr=0x7fffd61da760, pkt=0x7fb563769042 "") at snort.c:1404
> >> #14 0x00007fb56a9045f3 in ?? () from /usr/lib/daq/daq_afpacket.so
> >> #15 0x00000000004411f4 in DAQ_Acquire (max=<value optimized out>,
> >> callback=0x7fffd61d95ec, user=0x7fb5a1687700 "") at sfdaq.c:464
> >> #16 0x000000000042af8c in PacketLoop () at snort.c:2800
> >> #17 0x000000000042c09f in SnortMain (argc=<value optimized out>,
> >> argv=<value optimized out>) at snort.c:733
> >> #18 0x000000000042c0e5 in main (argc=1514, argv=0x5) at snort.c:665
> >>
> >>
> >> I'll work on getting a core dump and PCAP.  I do get full packet
> >> capture, but I have yet to be able to reproduce the problem when
> >> replaying the traffic...
> >>
> >> -Brett
> >>
> >> On Mon, Oct 3, 2011 at 9:59 PM, snort user <snort.user at ...2499...>
> wrote:
> >>> Hi Brett,
> >>>
> >>> Stream5GetApplicationData is called whenever an application needs to
> >>> retrieve any information that it saved/piggybacked onto the session
> >>> structure. You would see it in any of the preprocessors like dcerpc2
> >>> or smtp. I am assuming that you would have done a grep by now to
> >>> figure this out already.
> >>>
> >>> More importantly, would it be possible to provide
> >>>
> >>> 1. a stack trace ?
> >>> 2. the core file ?
> >>> 3. can you replicate the issue and if so can you capture the related
> >>> pcap when the issue occur ?
> >>>
> >>> These would be a great start to debug the issue and the list,
> >>> including me, would be able to help you out as well.
> >>>
> >>>
> >>> cheers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Oct 3, 2011 at 10:46 PM, Brett Edgar <brett.edgar at ...2499...>
> wrote:
> >>>> I am getting segfaults in spp_stream5.c on line 1368 and it's
> >>>> happening on multiple systems that have completely disjoint network
> >>>> traffic.  Somehow, the ssn pointer being passed into stream5 is not
> >>>> NULL (otherwise the if(ssnptr) would prevent the crash) but also not
> >>>> valid (since I'm getting a segfault).
> >>>>
> >>>> The systems that are exhibiting the problem are Gentoo systems.  Some
> >>>> are x86 and some are amd64.  The stream5 configurations are very
> >>>> similar between the systems.  Here is the stream5 configuration on one
> >>>> of the systems:
> >>>>
> >>>> preprocessor stream5_global: track_tcp yes, \
> >>>>   track_udp yes, \
> >>>>   track_icmp no, \
> >>>>   max_tcp 262144, \
> >>>>   max_udp 131072
> >>>> preprocessor stream5_tcp: policy windows, require_3whs 180, \
> >>>>   overlap_limit 10, small_segments 3 bytes 150, timeout 180, \
> >>>>    ports client 21 22 23 25 42 53 79 109 110 111 113 119 135 136 137
> 139 143 \
> >>>>        161 445 513 514 587 593 691 1433 1521 2100 3306 6070 6665 6666
> >>>> 6667 6668 6669 \
> >>>>        7000 8181 32770 32771 32772 32773 32774 32775 32776 32777 32778
> 32779, \
> >>>>    ports both 80 81 110 143 311 443 465 563 591 593 636 901 989 992
> >>>> 993 994 995 1220 1414 1830 2301 2381 2809 3128 3702 4343 5250 7907
> >>>> 7001 7145 7510 7802 7777 7779 \
> >>>>        7801 7900 7901 7902 7903 7904 7905 7906 7908 7909 7910 7911
> >>>> 7912 7913 7914 7915 7916 \
> >>>>        7917 7918 7919 7920 8000 8008 8014 8028 8080 8088 8118 8123
> >>>> 8180 8243 8280 8800 8888 8899 9080 9090 9091 9443 9999 11371 55555
> >>>> preprocessor stream5_udp: timeout 180
> >>>>
> >>>> That's very close, if not identical to, the snort.conf  in the VRT
> >>>> tarballs (except for the active response configuration statements in
> >>>> stream5_global that are not enabled because I didn't compile snort
> >>>> with that configuration option).
> >>>>
> >>>> I am a fairly competent C programmer, but I'm asking for suggestions
> >>>> on where to look in this mailing list since I am not familiar with the
> >>>> Snort code.  I'm hoping someone knows when Stream5GetApplicationData
> >>>> (the function that contains the segfault) gets called so I can narrow
> >>>> down my search more quickly...
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> All the data continuously generated in your IT infrastructure contains
> a
> >>>> definitive record of customers, application performance, security
> >>>> threats, fraudulent activity and more. Splunk takes this data and
> makes
> >>>> sense of it. Business sense. IT sense. Common sense.
> >>>> http://p.sf.net/sfu/splunk-d2dcopy1
> >>>> _______________________________________________
> >>>> Snort-devel mailing list
> >>>> Snort-devel at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
> >>>>
> >>>> Please visit http://blog.snort.org for the latest news about Snort!
> >>>>
> >>>
> >>
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20111005/dec78bf4/attachment.html>


More information about the Snort-devel mailing list