[Bro] Segmentation fault while using own signature.
Mike Dopheide
dopheide at gmail.com
Mon Jan 23 20:17:46 PST 2017
Fatema, thanks for continuing to dig into this.
"which is definitely not a port, and hence I changed the loose regex to
something like:
payload /.*([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\|[0-9]{1,5}).*/
to match the "<IP>|<Port>" more accurately, and only get triggered when
payload actually has a legit IP and port."
I had been running a regex similar to this already, but without the ( )'s.
I'd like clarification on if that's what ends up getting passed to the
signature match event as 'data'. I've added the ( ) 's today just in
case. Regardless, looks like I could do a little cleanup further into the
script logic as well. I really appreciate the feedback.
Interestingly, we just had a hit today that was an oddly formatted HTTP
Cookie, but it was just a "potential" and obviously didn't result in a
callback.
-Dop
On Mon, Jan 23, 2017 at 11:12 AM, fatema bannatwala <
fatema.bannatwala at gmail.com> wrote:
> Thank you all for helping to troubleshoot the problem. :) :)
> Finally, was able to get the issue resolved.
>
> So the problem boiled down to having very loose regex.
>
> The regex expression itself wasn't the problem, but the bro script that
> was using that signature was expecting a particular type of data type (port
> format),
> but since the regex was so loose that anything matching was passed onto
> the script, and then the script start complaining that the port format
> extracted is wrong.
> Following would help to clarify it more:
>
> my sig file had a signature with following payload match:
> (It was expected to match "<IP>|<port>" type of data in payload)
> payload /.*[0-9\.]{7,15}\|[0-9]{1,5}.*/
>
> And the bro script was splitting that particular chunk of data from the
> payload and assigning it to an IP n port type variable.
> v_port = to_port(fmt("%s/tcp",v_strs[i]));
>
> When I ran the script and sig file with a bro instance, got following
> error messages:
> /rootkit.bro, line 57: wrong port format, must be
> /[0-9]{1,5}\/(tcp|udp|icmp)/ (to_port(fmt(%s/tcp, Site::v_strs[Site::i])))
>
> Little troubleshooting revealed that the v_strs[i] was getting data like:
> 1;29645166|29663045|1;;cs=v%3fhttp://ad.doubleclick.net/
> dot.gif?1258562851900657 HTTP/1.1\x0d\x0aHost: ad...
>
> which is definitely not a port, and hence I changed the loose regex to
> something like:
> payload /.*([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\|[0-9]{1,5}).*/
> to match the "<IP>|<Port>" more accurately, and only get triggered when
> payload actually has a legit IP and port.
>
> Tested it and working so far without any seg fault/issues.
> Haven't tried on prod though.
>
> Mike - Don't know whether you came across this type of errors, but might
> also want to restrict the first payload to match <IP>|<port>.
>
> Thanks,
> Fatema.
>
>
>
> On Thu, Jan 19, 2017 at 6:33 AM, M A <zaixer at gmail.com> wrote:
>
>>
>> I have come across the same behavior while testing a script against some
>> odd PCAPs and found that most of the time tweaking the filter to be more
>> restrictive solved the issue. so, what you can do is:
>>
>> 1-Test against one signature only to determine which specific signature
>> causes the issue.
>> 2-Count # of "Potential rootkit" string existence for before and after
>> and see which one got more hits (supposedly this should be the one causing
>> the issue -less restrictive). This might validate that regex is working as
>> expected.....usage of debugging PRINT also might come handy.
>>
>> Thanks
>>
>>
>>
>> On 18 January 2017 at 22:30, fatema bannatwala <
>> fatema.bannatwala at gmail.com> wrote:
>>
>>> Thanks Jon for the links!
>>>
>>> Thanks Justin for alternative.
>>>
>>> We have our cluster in production, hence currently that sig file is
>>> disabled so that the cluster runs properly.
>>> Hence, to recreate the seg fault issue this time, rather than enabling
>>> it for the whole cluster, I just enabled it (in local.bro) for the previous
>>> version
>>> of bro that we still have around, and ran a single bro process for that
>>> old version, as you suggested.
>>> This time I was able to generate core dump for that single process.
>>>
>>> I ran the core dump through the crash-diag script:
>>>
>>> ============================================================
>>> ==============
>>> $ /usr/local/bro/2.4.1/share/broctl/scripts/crash-diag /tmp/brotest/
>>>
>>> Bro 2.5
>>> Linux 3.10.0-327.36.3.el7.x86_64
>>>
>>> core.bro-1484765328-89288
>>>
>>> Core was generated by `/usr/local/bro/2.4.1/bin/bro -i eth2 local'.
>>> Program terminated with signal 11, Segmentation fault.
>>> #0 0x00000000005ed589 in Func::Func (this=0x7ffd504940e0) at
>>> /home/fa/bro-2.5/src/Func.cc:63
>>>
>>> Thread 1 (LWP 89288):
>>> #0 0x00000000005ed589 in Func::Func (this=0x7ffd504940e0) at
>>> /home/fa/bro-2.5/src/Func.cc:63
>>> #1 0x00000000047dfaf0 in ?? ()
>>> #2 0x00007ffd504940e0 in ?? ()
>>> #3 0x0000000000000000 in ?? ()
>>>
>>> ==== No reporter.log
>>>
>>> ==== No stderr.log
>>>
>>> ==== No stdout.log
>>>
>>> ==== No .cmdline
>>>
>>> ==== No .env_vars
>>>
>>> ==== No .status
>>>
>>> ==== prof.log
>>> 1484765327.517900 TCP-States: Inact. Syn. SA Part.
>>> Est. Fin. Rst.
>>> 1484765327.517900 TCP-States:Inact. 454
>>> 1611 19 7
>>> 1484765327.517900 TCP-States:Syn. 2360 1027 12
>>> 262 34
>>> 1484765327.517900 TCP-States:SA 31 22
>>> 1484765327.517900 TCP-States:Part. 807 6489
>>> 1036 824 18
>>> 1484765327.517900 TCP-States:Est.
>>> 13778 3785 97
>>> 1484765327.517900 TCP-States:Fin. 61 619
>>> 3114 2401 33
>>> 1484765327.517900 TCP-States:Rst. 27 14 106
>>> 45 7
>>> 1484765327.517900 Connections expired due to inactivity: 37736
>>> 1484765327.517900 Total reassembler data: 21844K
>>>
>>> ==== packet_filter.log
>>> #separator \x09
>>> #set_separator ,
>>> #empty_field (empty)
>>> #unset_field -
>>> #path packet_filter
>>> #open 2017-01-18-13-44-17
>>> #fields ts node filter init success
>>> #types time string string bool bool
>>> 1484765057.522496 bro ip or not ip T T
>>>
>>> ==== loaded_scripts.log
>>> #separator \x09
>>> #set_separator ,
>>> #empty_field (empty)
>>> #unset_field -
>>> #path loaded_scripts
>>> #open 2017-01-18-13-44-17
>>> #fields name
>>> #types string
>>> /usr/local/bro/2.4.1/share/bro/base/init-bare.bro
>>> /usr/local/bro/2.4.1/share/bro/base/bif/const.bif.bro
>>> .......... (And a whole lot of loaded scripts, truncated)
>>>
>>> ============================================================
>>> =================
>>>
>>> The interesting thing is, I don't have such folder as: /home/fa/
>>> *bro-2.5/src*/Func.cc:63 in the home dir on that machine, where the
>>> error reported according to coredump.
>>> But located the Func.cc file and saw the function where the seg fault
>>> was reported:
>>>
>>> Func::Func() : scope(0), type(0)
>>> {
>>> unique_id = unique_ids.size();
>>> unique_ids.push_back(this);
>>> }
>>>
>>> Don't have much intuition though, that what have caused it :/
>>>
>>> Thanks,
>>> Fatema.
>>>
>>> On Wed, Jan 18, 2017 at 12:33 PM, Azoff, Justin S <jazoff at illinois.edu>
>>> wrote:
>>>
>>>>
>>>> > On Jan 18, 2017, at 11:56 AM, fatema bannatwala <
>>>> fatema.bannatwala at gmail.com> wrote:
>>>> >
>>>> > Hi Seth,
>>>> >
>>>> > Thanks for the suggestions, still getting No core dump:
>>>>
>>>> I'd just run bro from a shell.. you said it crashes pretty quickly
>>>> right?
>>>>
>>>> sudo su -
>>>> mkdir /tmp/brotest
>>>> cd /tmp/brotest
>>>> ulimit -c unlimited
>>>> /usr/local/bro/2.5/bin/bro -i eth0 local
>>>>
>>>> then it should crash and dump the core file right there.
>>>>
>>>> (replace eth0 with whatever)
>>>>
>>>> --
>>>> - Justin Azoff
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bro mailing list
>>> bro at bro-ids.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20170123/55e3b382/attachment.html
More information about the Bro
mailing list