[Bro] Segmentation fault while using own signature.
fatema bannatwala
fatema.bannatwala at gmail.com
Mon Jan 23 09:12:56 PST 2017
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/325fdd22/attachment.html
More information about the Bro
mailing list