Segmentation fault when installing tripwire on Ubuntu 20.10

Question

I am trying to install tripwire on Ubuntu 20.10. I have tried to install it with

sudo apt install tripwire

And then I've followed the usual steps outlined here. That gives me:

$ sudo tripwire --init
Please enter your local passphrase: 
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Software interrupt forced exit: Segmentation Fault
Segmentation fault

Next, I tried to build the whole thing from scratch as outlined here. That worked here, but not for me; It just gave me the same segmentation fault. How do I solve this? I checked file permissions in /etc/tripwire/, and they are all 644. I also looked at /var/crash/, and there is a _usr_sbin_tripwire.0.crash:

ProblemType: Crash

Architecture: amd64

CrashCounter: 1

Date: Thu May 13 16:55:22 2021

DistroRelease: Ubuntu 20.10

ExecutablePath: /usr/sbin/tripwire

ExecutableTimestamp: 1587715517

ProcCmdline: tripwire

ProcCwd: /home/.../tripwire-open-source-2.4.3.7

ProcEnviron:

 LANGUAGE=en_US:en

 LC_ADDRESS=es_ES.UTF-8

 LC_NAME=es_ES.UTF-8

 LC_MONETARY=es_ES.UTF-8

 LC_PAPER=es_ES.UTF-8

 LANG=en_US.UTF-8

 TERM=xterm-256color

 LC_IDENTIFICATION=es_ES.UTF-8

 LC_TELEPHONE=es_ES.UTF-8

 LC_MEASUREMENT=es_ES.UTF-8

 LC_TIME=es_ES.UTF-8

 PATH=(custom, no user)

 LC_NUMERIC=es_ES.UTF-8

 SHELL=/bin/bash

ProcMaps:

 00400000-00401000 r--p 00000000 fd:01 25952498                           /usr/sbin/tripwire

 00401000-0066d000 r-xp 00001000 fd:01 25952498                           /usr/sbin/tripwire

 0066d000-00706000 r--p 0026d000 fd:01 25952498                           /usr/sbin/tripwire

 00707000-0071c000 r--p 00306000 fd:01 25952498                           /usr/sbin/tripwire

 0071c000-00722000 rw-p 0031b000 fd:01 25952498                           /usr/sbin/tripwire

 00722000-00729000 rw-p 00000000 00:00 0 

 01c23000-01ca4000 rw-p 00000000 00:00 0                                  [heap]

 7fb20cf25000-7fb20d025000 rw-p 00000000 00:00 0 

 7fb20d025000-7fb20d026000 r--p 00000000 fd:01 25954640                   /usr/lib/x86_64-linux-gnu/ld-2.32.so

 7fb20d026000-7fb20d04a000 r-xp 00001000 fd:01 25954640                   /usr/lib/x86_64-linux-gnu/ld-2.32.so

 7fb20d04a000-7fb20d053000 r--p 00025000 fd:01 25954640                   /usr/lib/x86_64-linux-gnu/ld-2.32.so

 7fb20d053000-7fb20d054000 r--p 0002d000 fd:01 25954640                   /usr/lib/x86_64-linux-gnu/ld-2.32.so

 7fb20d054000-7fb20d056000 rw-p 0002e000 fd:01 25954640                   /usr/lib/x86_64-linux-gnu/ld-2.32.so

 7fb20d056000-7fb20d07c000 r--p 00000000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d07c000-7fb20d1e9000 r-xp 00026000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d1e9000-7fb20d235000 r--p 00193000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d235000-7fb20d236000 ---p 001df000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d236000-7fb20d239000 r--p 001df000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d239000-7fb20d23c000 rw-p 001e2000 fd:01 25958112                   /usr/lib/x86_64-linux-gnu/libc-2.32.so

 7fb20d23c000-7fb20d240000 rw-p 00000000 00:00 0 

 7fb20d240000-7fb20d243000 r--p 00000000 fd:01 25958121                   /usr/lib/x86_64-linux-gnu/libnss_files-2.32.so

 7fb20d243000-7fb20d24b000 r-xp 00003000 fd:01 25958121                   /usr/lib/x86_64-linux-gnu/libnss_files-2.32.so

 7fb20d24b000-7fb20d24d000 r--p 0000b000 fd:01 25958121                   /usr/lib/x86_64-linux-gnu/libnss_files-2.32.so

 7fb20d24d000-7fb20d24e000 r--p 0000c000 fd:01 25958121                   /usr/lib/x86_64-linux-gnu/libnss_files-2.32.so

 7fb20d24e000-7fb20d24f000 rw-p 0000d000 fd:01 25958121                   /usr/lib/x86_64-linux-gnu/libnss_files-2.32.so

 7fb20d24f000-7fb20d255000 rw-p 00000000 00:00 0 

 7fb20d271000-7fb20d278000 r--s 00000000 fd:01 26611939                   /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache

 7fb20d278000-7fb21aa56000 r--p 00000000 fd:01 25956329                   /usr/lib/locale/locale-archive

 7fb21aa56000-7fb21aab8000 rw-p 00000000 00:00 0 

 7ffe5608a000-7ffe560ab000 rw-p 00000000 00:00 0                          [stack]

 7ffe561b2000-7ffe561b6000 r--p 00000000 00:00 0                          [vvar]

 7ffe561b6000-7ffe561b8000 r-xp 00000000 00:00 0                          [vdso]

 ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

ProcStatus:

 Name:  tripwire

 Umask: 0022

 State: S (sleeping)

 Tgid:  170790

 Ngid:  0

 Pid:   170790

 PPid:  170789

 TracerPid: 0

 Uid:   0   0   0   0

 Gid:   0   0   0   0

 FDSize:    64

 Groups:    0 

 NStgid:    170790

 NSpid: 170790

 NSpgid:    170789

 NSsid: 65176

 VmPeak:      228636 kB

 VmSize:      228636 kB

 VmLck:        0 kB

 VmPin:        0 kB

 VmHWM:     4788 kB

 VmRSS:     4788 kB

 RssAnon:        908 kB

 RssFile:       3880 kB

 RssShmem:         0 kB

 VmData:        2048 kB

 VmStk:      132 kB

 VmExe:     2480 kB

 VmLib:     1644 kB

 VmPTE:       64 kB

 VmSwap:           0 kB

 HugetlbPages:         0 kB

 CoreDumping:   1

 THP_enabled:   1

 Threads:   1

 SigQ:  0/127780

 SigPnd:    0000000000000000

 ShdPnd:    0000000000000000

 SigBlk:    0000000000000000

 SigIgn:    0000000000001000

 SigCgt:    00000000418000fc

 CapInh:    0000000000000000

 CapPrm:    000000ffffffffff

 CapEff:    000000ffffffffff

 CapBnd:    000000ffffffffff

 CapAmb:    0000000000000000

 NoNewPrivs:    0

 Seccomp:   0

 Speculation_Store_Bypass:  thread vulnerable

 Cpus_allowed:  ffff

 Cpus_allowed_list: 0-15

 Mems_allowed:  00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001

 Mems_allowed_list: 0

 voluntary_ctxt_switches:   4

 nonvoluntary_ctxt_switches:    17

Signal: 11

Uname: Linux 5.8.0-50-generic x86_64

UserGroups: N/A

_LogindSession: c2

CoreDump: base64
...

Answer 1

For 22.04, the issue seems to stem from the fact that the package used is directly from Debian unstable instead of a package built specifically for Ubuntu 22.04.

A bug report can be found on launchpad.

Comment #3 in that bug report has a link to a PPA with the recompiled version.

That version has not yet crashed on me... It is likely that all the other tricks are not required with a properly compiled version.

Answer 2

I tried that trick again on another machine and it did not work. The --init command would still make tripwire crash.

I got the source, built a local version, and I tried running tripwire with gdb:

gdb tripwire
gdb> run --init

and it showed me that it crashes when it reaches getpwuid(). A really strange one! (see Why does it crash? below)

Looking at the UID and searching about SEGV and the very function crashing on Google, I found out that, in some circumstances, if that function gets called with an unknown user (a UID not defined in /etc/passwd) then it crashes. With that version, in my case I was told that user 501 did not exist. So it was then a matter of searching for files with that user identifier and deleting the files or fixing their ownership with an existing user. I have more details on my Linux page here about all of that.

And that's why the trick of removing certain sections from the twpol.cfg works at times. Also if you update your configuration file, don't forget to recompile it before attempting the tripwire --init again.

Why does it crash?

The tripwire code does two things:

1. it makes use of a global variable marked as thread safe; and
2. it is compiled statically.

Somehow, when trying to access that thread safe variable, we get a null pointer and the code then tries to access the data at that pointer: SEGV.

This is something at the g++/gcc and libc level. That is, a variable marked as thread safe is a compiler feature. It is implemented by calling functions in libc.

The reason for the crash is that the function checking for the user is loaded dynamically (i.e. NSS module). For that dynamically loaded code to work properly, it has to be 100% compatible with the libc tripwire was linked against. If not, you get that null pointer and then the dereference of that pointer results in a SEGV.

Are there other situations when it will crash in such a way?

Yes. If your Linux system has mount points to devices where files have ownerships not represented in your local /etc/passwd, then the same issue occurs. For those, you probably want to keep those mount points, so the best is to fix the twpol.txt to make sure that those files do not get checked. That is sufficient to avoid the SEGV.

But my --init worked, it has been months, why is tripwire failing now?

Just the same as above. If you create a file with an unknown user in a directory that tripwire is going to check, it will create that SEGV. The same process is required: remove the file from what tripwire processes.

Compiling Project without --enable-static

As found in this bug report on Debian, it is possible to remove the static option by editing the debian/rules file.

First get the source:

mkdir tripwire
apt-get source tripwire

Then edit debian/rules and change:

dh_auto_configure -- --disable-openssl --enable-static --sysconfdir=/etc/tripwire

Into:

dh_auto_configure -- --disable-openssl --sysconfdir=/etc/tripwire

Recompile and that version will not crash. Install your new package. You're good to go.

Hopefully, at some point a maintainer will accept the fact/idea that tripwire needs to run rather than be as safe as possible (actually a SEGV is probably worse than using shared libraries).

Reported Bug

Thinking that since it comes from a C/C++ construct, I posted the bug on gnu.org here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113211

Andrew Pinski found two other bug reports in link with a similar SEGV:

https://github.com/systemd/systemd/issues/29337

https://www.mail-archive.com/[email protected]/msg1827372.html

From the systemd issue, here is a pertinent comment by poettering:

I am only seeing this now: so getpwuid() is generally provided by glibc. But in your stacktrace it looks like it's part of your coreutils binary? what kind of weird mess is that? some static binary or so? and then you load nss-systemd into it, which links a different glibc version? how is that not supposed to break if you use any reasonably non-trivial concept?

Sorry, but this seems to be some clearlinux shit they really need to deal with themselves. Static binaries and NSS is just nuts, if they try that they have to deal with the fallout. Sorry if that's disappointing.

So it sounds like that happens because tripwire is compiled statically to decrease chances that it gets messed up by a hacker (I would imagine) since otherwise any .so library loaded by tripwire could be transformed by a hacker and then tripwire would not function as intended.