在 Ubuntu 20.10 上安装 tripwire 时出现分段错误

在 Ubuntu 20.10 上安装 tripwire 时出现分段错误

我正在尝试在 Ubuntu 20.10 上安装 tripwire。我尝试使用

sudo apt install tripwire

然后我按照通常的步骤这里。这给了我:

$ 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

接下来,我尝试按照概述从头开始构建整个东西这里. 成功了这里,但对我来说不是;它只是给了我相同的分段错误。我该如何解决这个问题?我检查了 /etc/tripwire/ 中的文件权限,它们都是 644。我还查看了 /var/crash/,有一个 _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
...

答案1

对于 22.04,问题似乎源于所使用的软件包直接来自 Debian stable,而不是专门为 Ubuntu 22.04 构建的软件包。

可以在启动板上找到错误报告

该错误报告中的评论#3 有带有重新编译版本的 PPA 链接

该版本还没有在我这里崩溃...使用正确编译的版本可能不需要所有其他技巧。

答案2

我在另一台机器上再次尝试了这个技巧,但没有奏效。该--init命令仍然会导致tripwire崩溃。

我获得了源代码,构建了一个本地版本,并尝试使用 gdb 运行 tripwire:

gdb tripwire
gdb> run --init

并显示当达到时它会崩溃getpwuid()。真是奇怪!(见为什么会崩溃?以下)

查看 UID 并在 Google 上搜索有关 SEGV 和崩溃函数的信息后,我发现在某些情况下,如果该函数被未知用户(未在 中定义的 UID /etc/passwd)调用,则它会崩溃。对于该版本,就我而言,我被告知用户 501 不存在。因此,接下来需要搜索具有该用户标识符的文件并删除这些文件或将其所有权修复为现有用户。我有更多详细信息我的 Linux 页面在这里关于所有这些。

这就是为什么要从twpol.cfg 作品有时。另外,如果您更新了配置文件,请不要忘记在tripwire --init再次尝试之前重新编译它。

为什么会崩溃?

tripwire 代码做了两件事:

  1. 它使用标记为线程安全的全局变量;并且
  2. 它是静态编译的。

不知何故,当尝试访问该线程安全变量时,我们会得到一个null指针,然后代码尝试访问该指针处的数据:东风风神

这是 g++/gcc 和 libc 层面的事情。也就是说,标记为线程安全的变量是编译器的特性。它是通过调用 libc 中的函数来实现的。

崩溃的原因是检查用户的功能动态加载(即 NSS 模块)。要使动态加载的代码正常工作,它必须与所链接的 libc tripwire 完全兼容。如果不兼容,您将获得该null指针,然后取消引用该指针会导致 SEGV。

还有其他情况也会以这种方式崩溃吗?

是的。如果您的 Linux 系统具有指向设备的挂载点,而这些设备的文件的所有权未在本地 中表示/etc/passwd,则会出现相同的问题。对于这些,您可能希望保留这些挂载点,因此最好的方法是修复twpol.txt以确保不会检查这些文件。这足以避免 SEGV。

但是我的--init工作已经过去好几个月了,为什么绊线现在失效了?

与上面相同。如果您在 tripwire 将要检查的目录中使用未知用户创建文件,它将创建该 SEGV。需要相同的过程:从 tripwire 进程中删除该文件。

编译项目时无需--enable-static

正如在Debian 上的这个错误报告,可以通过编辑debian/rules文件来删除静态选项。

首先获取源码:

mkdir tripwire
apt-get source tripwire

然后编辑debian/rules并更改:

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

进入:

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

重新编译,该版本不会崩溃。安装新软件包。一切就绪。

希望在某个时候维护者能够接受这样的事实/想法,即 tripwire 需要运行而不是尽可能安全(实际上 SEGV 可能比使用共享库更糟糕)。

已报告错误

由于我认为它来自 C/C++ 构造,因此我将这个错误发布在了 gnu.org 上:

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

Andrew Pinski 在链接中发现了另外两个与类似 SEGV 相关的错误报告:

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

https://www.mail-archive.com/[电子邮件保护]/msg1827372.html

从 systemd 问题来看,这里有一个 poettering 的相关评论:

我现在才看到这一点:sogetpwuid()通常由 glibc 提供。但在你的堆栈跟踪中,它看起来像是你 coreutils 二进制文件的一部分?那是什么样的奇怪混乱?一些静态二进制文件之类的?然后你将 nss-systemd 加载到其中,它链接了不同的 glibc 版本?如果你使用任何相当不平凡的概念,这怎么可能不被破坏呢?

抱歉,但这似乎是 clearlinux 需要他们自己处理的一些问题。静态二进制文件和 NSS 简直是疯了,如果他们尝试这样做,他们就必须处理后果。如果这令人失望,我很抱歉。

所以听起来发生这种情况是因为 tripwire 是静态编译的,以减少被黑客搞乱的机会(我想象),否则 tripwire 加载的任何 .so 库都可能被黑客转换,然后 tripwire 将无法按预期运行。

相关内容