Tripwire crash on Ubuntu 16.04 LTS

[jm-duke]

Hi,

I'm testing Tripwire Open Source on Ubuntu 16.04 LTS, but as soon as I run "tripwire --init" it crashes
with a segmentation fault:

root@xxx:~# tripwire --init -v
Open Source Tripwire(R) 2.4.3.1.0 built for x86_64-pc-linux-gnu
[...]
--- Generating information for: /usr/sbin/zic
Processing: /usr/sbin/siggen
--- Generating information for: /usr/sbin/siggen
Processing: /usr/sbin/tripwire
--- Generating information for: /usr/sbin/tripwire
Software interrupt forced exit: Segmentation Fault

A backtrace from gdb:
(gdb) bt
#0 0x0000000000000421 in ?? ()
#1 0x000000000043e679 in cFCONameTbl::Clear() ()
#2 0x000000000043e6ee in cFCONameTbl::~cFCONameTbl() ()
#3 0x00000000005818b8 in __run_exit_handlers ()
#4 0x0000000000581903 in exit ()
#5 0x000000000043679d in util_SignalHandler(int) ()
#6
#7 0x0000000000000000 in ?? ()
#8 0x00007f9769235fe9 in __pthread_initialize_minimal_internal () at nptl-init.c:471
#9 0x00007f97692355d1 in _init () at ../sysdeps/x86_64/crti.S:72
#10 0x00007f976944df58 in ?? () from /lib/x86_64-linux-gnu/libnss_sss.so.2
#11 0x000000000062f25a in call_init.part ()
#12 0x000000000062f415 in _dl_init ()
#13 0x0000000000620d35 in dl_open_worker ()
#14 0x000000000061e4f4 in _dl_catch_error ()
#15 0x0000000000620699 in _dl_open ()
#16 0x00000000005f2672 in do_dlopen ()
#17 0x000000000061e4f4 in _dl_catch_error ()
#18 0x00000000005f285e in __libc_dlopen_mode ()
#19 0x00000000005edd2d in __nss_next2 ()
#20 0x00000000005e34a0 in getpwuid_r ()
#21 0x00000000005e32a6 in getpwuid ()
#22 0x0000000000483706 in cUnixFSServices::GetOwnerForFile(std::__cxx11::basic_string<char, std::char_traits,

std::allocator > const&, std::cxx11::basic_string<char, std::char_traits, std::allocator >&) const ()
#23 0x000000000044922a in cFSPropDisplayer::InitForProp(iFCO const*, int) ()
#24 0x000000000044a0e1 in cFSPropDisplayer::InitForFCO(iFCO const*) ()
#25 0x000000000040ef1d in cTripwireUtil::CalcProps(iFCO, iFCOSpec const, iFCOPropCalc_, iFCOPropDisplayer_) ()
#26 0x000000000040145a in cGenerateDb::Execute(cFCOSpecList const&, cHierDatabase&, iFCOPropDisplayer_, cErrorBucket_, unsigned int) ()
#27 0x000000000041b056 in cTWModeDbInit::Execute(cErrorQueue*) ()
#28 0x000000000040db1f in main ()

Cheers,
Tom.

[brc0x1]

Hi Tom, I think I understand the problem here. You're probably using a statically linked binary that was linked against a different glibc version (for example, if it was built on Ubuntu 14.04) Even though the binary itself is linked statically, the getpwuid() call wants to load shared libraries in the background to do uid -> name resolution. Since you have a static copy of glibc, the .so names and locations and so forth that it wants to use are baked in, and it falls over if its expectations aren't met.

So assuming the problem is what I think it is, you have a couple of options:

• Build static binaries on your 16.04 box, so they're linked against the "right" glibc.
• Build dynamically linked binaries, so you don't have to worry about glibc versioning.
• I don't really want to suggest not monitoring the owner & group attributes, but it would avoid the code path where your db init falls over.

This has come up enough that I'm wondering if it would be useful to add a config option to turn off uid/gid -> name resolution, and just report numeric IDs. That ought to let you use a static binary anywhere, at the cost of somewhat more cryptic output. Ideally I'd prefer to detect the glibc mismatch situation automatically and set this option without a manual configuration step, but I've never come across a good programmatic way of detecting this.

[jm-duke]

Hi Brian,

thanks for coming back to me.

The tripwire binary I use is one I built from the sources on an Ubuntu 16.04 LTS host, so it should be linked against the right glibc (p.s.: Before compiling from source I tried the tripwire binaries shipped with Xenial, those crash as well.)

I did some more testing this morning and also tried linking the tripwire binaries dynamically. E voila, the dynamically linked tripwire binary runs smoothly without crashing. As soon as the tripwire DB is in place, i can run "tripwire --check" with the statically linked binary and it won't crash either.

Cheers,
Tom.

[brc0x1]

I'm glad the dynamic link option worked for you. I spun up a fresh 16.04 LTS vm to investigate the static situation further, and both the static & dynamic binaries I built appear to work correctly. So I'm not sure what's different between your system and mine. I've got kernel 4.4.0-31-generic, glibc 2.23-0ubuntu3, and gcc/g++ 5.4.0. And for name lookups, my /etc/nsswitch.conf is unmodified, and the vm isn't configured to use NIS or LDAP.

[jm-duke]

My kernel is more recent, 4.4.0-45-generic. but glibc and gcc/g++ are the same version.

But here comes the interesting part: nsswitch.conf is modified, because we use AD as user back-end. I installed tripwire on another machine, which is not AD integrated yet. On this server tripwire runs smoothly as well, no crash. So the crash of the static binary is linked to our server's using AD as authentication back-end.

Cheers,
Tom.

[brc0x1]

Ok, I got around to creating the config option I mentioned earlier; the 2.4.3.2 update will add a RESOLVE_IDS_TO_NAMES boolean config option -- if true (or unset) things work the way they do now. If false, we stick with numeric UIDs & GIDs, and avoid any name resolution stuff that could make a static binary fall over.

[jm-duke]

Perfect, thank you!

[brc0x1]

Ok, I wrapped up & merged the 2.4.3.2 update a couple of days ago, and it includes the new RESOLVE_IDS_TO_NAMES option.