Segmentation fault on Ubuntu 20.10

[ElToro1966]

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. 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

[brc0x1]

Hi ElToro1966, sorry this is happening for you. Couple of quick ideas --

• If you're using statically-linked binaries, and the machine is doing user/group name lookups through LDAP or AD, those two things don't always play nice together, and you might need to set the RESOLVE_IDS_TO_NAMES config value to false in your tw.cfg to work around this. More details about this in issue Tripwire crash on Ubuntu 16.04 LTS #11 .
• If you run a check or db init with the "--verbose" arg, it will list the objects it's visiting as it scans them, which is useful if it's stumbling over a specific object covered by your policy file. If that's what's happening, then we can investigate what might be special about that object.
• I admit I'm not an expert on Ubuntu's "apport" crash handling system, but they recommend using a tool called apport-retrace to get readable stack traces after a program crash. If you feel like trying this and it works for you, that stack trace would be very helpful in understanding what's going on here.

In the meantime, I'll spin up a 20.10 VM (with an es_ES.UTF-8 locale) and install with apt-get and see if I have any luck reproducing this.

[mohamed-okasha]

Thanks, @brc0x1
I spent several hours trying to figure out the issue, I thought the problem was with the virtual machine...

My virtual machine in the VMware ESXi Hypervisor with HW Spec:
CPU: 8 vCPUs
RAM: 24 GB
HARD DISK: 128 GB

And OS: Ubuntu 20.04.2 LTS (focal)
I am also experiencing the same issue:

After setting the RESOLVE_IDS_TO_NAMES config value to false in tw.cfg the problem has been resolved;

[OmlineEditor]

I have a similar problem.
first there was a mistake: Software interrupt forced exit: Segmentation Fault
I added
RESOLVE_IDS_TO_NAMES =false
in tw.cfg

the previous error disappeared but a new error appeared:
Software interrupt forced exit: Segmentation Fault
Software interrupt forced exit: Emulation Trap

before the error was the output of the file name that is being processed, I added them to the exceptions, but it did not help.

how can this be solved?

[brc0x1]

HI @OmlineEditor, are you on Ubuntu 20.x also? When this happens, is the machine using any sort of directory service (LDAP/Active Directory, NIS, etc.) If setting RESOLVE_IDS_TO_NAMES didn't fix this for you, your best bet is probably going to be to rebuild from source without enabling static linking.

[OmlineEditor]

HI @OmlineEditor, are you on Ubuntu 20.x also? When this happens, is the machine using any sort of directory service (LDAP/Active Directory, NIS, etc.) If setting RESOLVE_IDS_TO_NAMES didn't fix this for you, your best bet is probably going to be to rebuild from source without enabling static linking.

Where can I get detailed instructions on how to do this?

[brc0x1]

@OmlineEditor Here's the readme section about building from source: https://github.com/Tripwire/tripwire-open-source/blob/master/README.md#building-ost . Let me know if you run into any difficulties or have any questions.

[G0rd0n]

Brief question. I cannot $ sudo nano /etc/tripwire/tw.cfg because the file contents appear as random symbols (the encryption?)
Though, even after unencrypting* with $ sudo twadmin -m R /etc/tripwire/tw.cfg it still would not display any intelligible readout, neither with sudo nano or sudo cat.
What am I missing?
*( After fiddling I encrypted again with $ sudo twadmin -m E /etc/tripwire/tw.cfg )

[brc0x1]

Hi @G0rd0n , to see the plaintext version of your config file, you'll need to use a different twadmin mode for that: twadmin -m f or twadmin --print-cfgfile . This is because a decrypted tw.cfg is still in a compressed binary form. If you have a plaintext config file and want to create or update a tw.cfg file, the mode for that is twadmin -m F or twadmin --create-cfgfile, and there's a similar pair of modes for creating and displaying policy files.

[G0rd0n]

Okay, that actually makes sense. I will dig a bit deeper into this.
Thank you for helping and explaining more about this product.

[karolk53]

Hi @G0rd0n, can u wirte, me a command how i can edit tw.cfg? I'am a beginner and I don't know how to do this.

[G0rd0n]

@karolk53 I can't really help you with this. I am just as much a novice as you are : P
I haven't actually worked on this since my last post, so I would need to re-read a lot of stuff again. If I could spare the time then I could probably make it work, but it is on the backburner for now.

[OmlineEditor]

Hi @G0rd0n, can u wirte, me a command how i can edit tw.cfg? I'am a beginner and I don't know how to do this.

install a file manager and edit through it using the F4 key.

installation for ubuntu or Debian:
apt install mc

run programm, type the command as root
mc

go to the desired folder select the file and press F4

[dad98253]

I encountered the same problem when I upgraded to 22.04. Your RESOLVE_IDS_TO_NAMES fix resolved the issue.
However, now it segfaults near the end of the tripwire -init run when attempting to access the /tmp folder...
The /tmp folder has the sticky bit set on its permissions. I'll experiment to see if this effects the result...
Does anyone know if this issue will be corrected in the future?
p.s., My ubuntu 22.04 machine is not a member of a samba AD domain nor does it use NIS.

[zodman]

For me this works:

cd /etc/tripwire
echo "RESOLVE_IDS_TO_NAMES=false" >> twcfg.txt
twadmin -m F -c tw.cfg -S site.key twcfg.txt
tripwire --init 
....
The database was successfully generated. 

[dad98253]

On ubuntu after upgrading from 20.04 to 22.04, tripwire will segfault using policy and config files that worked under 20.04 and also after a fresh tripwire install using the default policy and config. The inclusion of RESOLVE_IDS_TO_NAMES = false in the config file only moves the point at which it will segfault. With RESOLVE_IDS_TO_NAMES = false set, the fault appears to occur at the very end of the run after the final file has been checked. Without the RESOLVE_IDS_TO_NAMES setting, the segfault occurs near the beginning of the run. (Note that this was run on an ubuntu install that was upgraded using the do-release-upgrade command on August 16, 2022. I have not tested tripwire on a fresh install of 22.04. The tripwire version is 2.4.3.7.0 built for x86_64-pc-linux-gnu. The date on the released tripwire executable is Nov 10 2021 and its size is 3140528 bytes.)
Running tripwire under gdb does no good because it appears that all symbols have been striped from the released tripwire executable. It will segfault, but the backtrace is useless without symbols.
I downloaded the tripwire source from the ubuntu 22.04 repository and recompiled it. However, it does not segfault. The apt-get --build command built the new executable with symbols and it is statically linked. So, I can't tell if the fresh compile is actually free of the problem (possibly due to statically linking to whatever libraries are on my computer) or if by including symbols or some other compiler option difference, the segfault problem was moved somewhere else. In any case, I have a working version of tripwire for now.
Luckily, I found this on my desktop computer before running the 22.04 upgrade on any of my servers! Hopefully, the maintainers will provide a working released version of tripwire at some point in the future.

[chelo1994]

Has anyone found a solution? I made all kinds of changes as above, but the fix works for a few days, the same error happens again.
Thank you!!

[OmlineEditor]

Has anyone found a solution? I made all kinds of changes as above, but the fix works for a few days, the same error happens again. Thank you!!

there is no solution, you need to fix the sources

[dad98253]

Same here... My re-compiled version worked for a while and now it segfaults, too.

--- edit: Hmm... My recompiled version has been working fine for months now. I'm not sure why I thought it stopped working. Maybe I referenced the released copy by mistake? I completely removed the installed version and did a make install of my recompiled version. It appears to work. I'm not sure what the problem was.

[Moaht]

Same here... My re-compiled version worked for a while and now it segfaults, too.

Did you manage to get it to work on 22?
I'm having the same issue...

[davygravy]

@zodman's fix shown in #48 (comment) worked for me... at least for now. This is on a fresh Debian 11.6 install, fail2ban 0.11.2-2 from Debian standard packages (Bullseye). [ https://packages.debian.org/bullseye/fail2ban ]

For comparison, it seems that Ubuntu Kinetic (22) is versioned : fail2ban_0.11.2-6.debian.tar.xz in its source... I haven't compared the context between Debian vs. Ubuntu, so I'm not unaware as to what patches/changes are present in the 0.11.2-6.

Yes, I experienced the same segfaulting issue that is reference above. Not sure that this is the same issue/causality that Ubuntu users are experiencing, TBH.

[chelo1994]

@zodman's fix shown in #48 NOT worked for me.
On Debian 11.

---

... Processing: /tmp
--- Generating information for: /tmp
Software interrupt forced exit: Segmentation Fault
Segmentation fault

---

Any idea? thanks

[dad98253]

Was this ever resolved? Is it safe to reinstall the released version, yet?
Do any developers read these posts? Or are we just posting into the ether?

[OmlineEditor]

Was this ever resolved? Is it safe to reinstall the released version, yet? Do any developers read these posts? Or are we just posting into the ether?

the project is dead, the last changes were 5 years ago. no one will fix anything

[S-A-L13]

I had the same problem with a freshly installed Debian 12 (Bookworm).
Setting RESOLVE_IDS_TO_NAMES=false in twcfg.txt helped but I think it's more like a workaround than a solution. Because this parameter should only be necessary if you use UIDs/GIDs from non-local directory servers like Active Directory or different LDAP servers. In this case the local system can't resolve the names (it can't find the username for UID 1001 or groupname for GID 2002). But on a standalone system without connection to NIS/LDAP/AD servers it should resolve every UID/GID.

The real problem on my system were wrong file permissions for the folder /usr/lib/firmware/intel/ and all subfolders and files within them. UID and GID were set to 3064 and 1199. Looks like a bug in the debian package that provides these files.
Solved the problem by setting the same owner & group to this folder like all other folders within /usr/lib/firmware/ with:
chown -R root:root /usr/lib/firmware/intel

You can find the problematic folder with:
tripwire --init -v
with -v it will show all folders it's parsing. The last folder it's showing before the error occurs is the folder that makes trouble.

Hope this will help the one ore the other :)

[dad98253]

Thanks, I'll give that a try when I have access to the problem computer again (next March). FYI, when I tried a fresh installation of ubuntu in a virtual machine, tripwire appeared to work fine right out of the box... On Friday, October 27, 2023 at 11:12:53 PM GMT+8, S-A-L13 ***@***.***> wrote: I had the same problem with a freshly installed Debian 12 (Bookworm). Setting RESOLVE_IDS_TO_NAMES=false in twcfg.txt helped but I think it's more like a workaround than a solution. Because this parameter should only be necessary if you use UIDs/GIDs from non-local directory servers like Active Directory or different LDAP servers. In this case the local system can't resolve the names (it can't find the username for UID 1001 or groupname for GID 2002). But on a standalone system without connection to NIS/LDAP/AD servers it should resolve every UID/GID. The real problem on my system were wrong file permissions for the folder /usr/lib/firmware/intel/ and all subfolders and files within them. UID and GID were set to 3064 and 1199. Looks like a bug in the debian package that provides these files. Solved the problem by setting the same owner & group to this folder like all other folders within /usr/lib/firmware/ with: chown -R root:root /usr/lib/firmware/intel You can find the problematic folder with: tripwire --init -v with -v it will show all folders he is parsing. The last folder it's showing before the error occurs is the folder that makes trouble. Hope this will help the one ore the other :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>