bro segfaults on startup

Zeek
1

Which packet filter do you mean?

I meant the libpcap. But:

Scott Campbell mentioned it may be a problem with the resolver library,
as others have had similar problems in the past.

this is clearly the problem, given the traceback that terminates inside
the resolver library:

(gdb) run -i eth0 mt http ftp scan
Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan

Program received signal SIGSEGV, Segmentation fault.
0x0000000000561ef5 in __ns_initparse ()
(gdb) bt
#0 0x0000000000561ef5 in __ns_initparse ()
Cannot access memory at address 0xffd2a510

This may be a longshot, but in the past folks have worked around resolver
problems on Linux but linking to /usr/lib/libresolv.a directly. Worth
giving a try.

FWIW, we run without problems on Red Hat 2.4.21. But we're not running
64-bit native, which it looks like you are. (Our glibc is a slightly older,
but I don't imagine that matters.)

Scott, do you recall any other fixes?

    Vern

2

Vern Paxson wrote:

Which packet filter do you mean?

I meant the libpcap. But:

Scott Campbell mentioned it may be a problem with the resolver library,
as others have had similar problems in the past.

this is clearly the problem, given the traceback that terminates inside
the resolver library:

(gdb) run -i eth0 mt http ftp scan
Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan

Program received signal SIGSEGV, Segmentation fault.
0x0000000000561ef5 in __ns_initparse ()
(gdb) bt
#0 0x0000000000561ef5 in __ns_initparse ()
Cannot access memory at address 0xffd2a510

This may be a longshot, but in the past folks have worked around resolver
problems on Linux but linking to /usr/lib/libresolv.a directly. Worth
giving a try.

FWIW, we run without problems on Red Hat 2.4.21. But we're not running
64-bit native, which it looks like you are. (Our glibc is a slightly older,
but I don't imagine that matters.)

Scott, do you recall any other fixes?

    Vern
_______________________________________________
Bro mailing list
bro@bro-ids.org
mailman.icsi.berkeley.edu Mailing Lists

Unfortunately I suggested that our discussion get punted back to the
list since I have no experience with the 64 bit libs on linux. I
suspect that you may be correct about the linking. If that does not
work you may want to explore forcing the issue of compiling & running in
32 bit mode.

If this continues to be a problem, I can ask around here and see what
other peoples suggestions are.

scott

3

Ah, 64 bit and resolver-problems, that rings a bell: I've seen
core-dumps on a 64bit SUSE Linux which were caused by linking in the
32bit version of the resolver-library. However, I recall that there
was a corresponding warning during compiling/linking (which was easy
to miss though). David, do you see anything like this?

Robin

4

Robin Sommer wrote:

Ah, 64 bit and resolver-problems, that rings a bell: I've seen
core-dumps on a 64bit SUSE Linux which were caused by linking in the
32bit version of the resolver-library. However, I recall that there
was a corresponding warning during compiling/linking (which was easy
to miss though). David, do you see anything like this?

Yes, during the compile of bro the following message is seen:

g++ -g -O2 -o bro dce_rpc_pac.o ncp_pac.o smb_pac.o main.o net_util.o util.o parse.o scan.o re-parse.o re-scan.o rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o Base64.o BPF_Program.o BroString.o CCL.o ChunkedIO.o CompHash.o Conn.o ConnCompressor.o DCE_RPC.o DFA.o DNS.o DNS_Mgr.o DbgBreakpoint.o DbgHelp.o DbgWatch.o Debug.o DebugCmds.o DebugLogger.o Desc.o Dict.o Discard.o EquivClass.o Event.o EventHandler.o EventRegistry.o Expr.o FTP.o File.o Finger.o Frag.o Frame.o Func.o Gnutella.o HTTP.o Hash.o ICMP.o ID.o Ident.o IntSet.o InterConn.o IOSource.o IRC.o List.o Logger.o Login.o MIME.o NCP.o NFA.o NFS.o NTP.o NVT.o Net.o NetVar.o NetbiosSSN.o Obj.o OSFinger.o PacketFilter.o PacketSort.o PersistenceSerializer.o PktSrc.o PolicyFile.o POP3.o Portmap.o PrefixTable.o PriorityQueue.o Queue.o RE.o RPC.o Reassem.o RemoteSerializer.o Rlogin.o RSH.o Rule.o RuleAction.o RuleCondition.o RuleMatcher.o ScriptAnaly.o SMB.o SmithWaterman.o SMTP.o SSH.o Scope.o SerializationFormat.o SerialObj.o Serializer.o Sessions.o StateAccess.o Stats.o SteppingStone.o Stmt.o TCP.o TCP_Contents.o TCP_Endpoint.o TCP_Rewriter.o Telnet.o Timer.o Traverse.o TwoWise.o Type.o UDP.o Val.o Var.o XDR.o bsd-getopt-long.o cq.o md5.o patricia.o setsignal.o version.o strsep.o nb_dns.o X509.o SSLCiphers.o SSLInterpreter.o SSLProxy.o SSLv2.o SSLv3.o SSLv3Automaton.o -Llibedit -ledit -L../aux/libpcap-0.7.2 -lpcap -lresolv -lz /usr/lib/libresolv.a -lssl -lcrypto /usr/lib/libresolv.a -ltermcap -lm
/usr/bin/ld: warning: i386 architecture of input file `/usr/lib/libresolv.a(ns_parse.o)' is incompatible with i386:x86-64 output

I assume that is the error we are looking for. Unfortunately, it seems that removing the references to /usr/lib/libresolv.a in each of the Makefiles causes ns_initparse to go undefined and make fails:

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -I/include -c `test -f nb_dns.c || echo './'`nb_dns.c
gcc -g -O2 -I/include -o hf hf.o setsignal.o version.o nb_dns.o -L../../aux/libpcap-0.7.2 -lpcap -lresolv -lz -lssl -lcrypto -ltermcap
nb_dns.o(.text+0x671): In function `nb_dns_activity':
/raid/work/bro-1.0/aux/hf/nb_dns.c:476: undefined reference to `__ns_initparse'
nb_dns.o(.text+0x7ae):/raid/work/bro-1.0/aux/hf/nb_dns.c:519: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x7ca):/raid/work/bro-1.0/aux/hf/nb_dns.c:519: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x93c):/raid/work/bro-1.0/aux/hf/nb_dns.c:561: undefined reference to `__ns_parserr'
collect2: ld returned 1 exit status
make[4]: *** [hf] Error 1
make[4]: Leaving directory `/raid/work/bro-1.0/aux/hf'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/raid/work/bro-1.0/aux'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/raid/work/bro-1.0/aux'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/raid/work/bro-1.0'
make: *** [all] Error 2

I'll look into it more, figured you might like an update though.

5

That sounds indeed familiar. On the SUSE system, this hack solved
the problem:

(1) Patching configure.in:

--- configure.in~ 2005-12-22 01:12:21.000000000 +0100
+++ configure.in 2005-12-22 01:12:21.000000000 +0100
@@ -241,7 +241,7 @@
dnl Specifying a specific resolver library seems to work/be necessary
dnl on all OSs, but Darwin needs -lresolv instead of
/usr/lib/libresolv.a
dnl We define the default here and overwrite below. --ck
-bro_libresolv="/usr/lib/libresolv.a"
+bro_libresolv="/usr/lib64/libresolv.a"

case "$target_os" in

(2) Running ./autogen.sh

(3) LDFLAGS=-L/usr/lib64/termcap/ ./configure

Robin

6

Robin Sommer wrote: