☰

什么（除软件更新之外）可以更新系统可执行文件？

tag-icon • tag-icon updates checksums
什么（除软件更新之外）可以更新系统可执行文件？

当软件更新程序弹出一些要安装的更新时，我会在应用它们之前运行 rkhunter，以检查我的安装是否干净。完成后，我会更新 rkhunter 的文件签名。

最近我发现 rkhunter 报告了这些更新之间系统和重要可执行文件的变化。Cron 和 curl，甚至 bash 本身，今天在最新更新之前，我发现 dpkg 已经发生了变化。

这是某种漏洞的证据吗？包括 rkhunter 本身在内的标准恶意软件检查从未报告过问题。

如果我知道在哪里可以找到可疑可执行文件的 md5 校验和，我就可以比较它们。我猜软件更新过程会进行一些这样的检查。我的 /etc/apt/sources.list 仅包含标准存储库。我的某个 PPA 会不会以某种方式这样做/可疑？PPA 能否通过软件更新程序以外的其他方式更新这些？我没有运行 Livepatch。

答案1

这是某种漏洞的证据吗？包括 rkhunter 本身在内的标准恶意软件检查从未报告过问题。

不可以。这种软件容易出现误报。

我的某个 PPA 会不会以某种方式执行此操作或存在可疑行为？PPA 是否可以通过软件更新程序以外的其他方式更新这些内容？

我们的所有更新都来自存储库，所有安全更新都来自安全存储库。Ubuntu 反向移植安全补丁，以便软件（如 apt 和 cURL）能够保持安全，而不会因更改版本而破坏其他软件。

什么（除软件更新之外）可以更新系统可执行文件？

您安装的任何软件包，如果依赖 apt 或 curl，且列出的版本号高于您发布的正常存储库中的版本号，则将因版本不匹配而出错。较低版本不会触发更新，但如果软件包有“最多此版本”，也会出错。混合发布会触发安装最高版本；固定软件包会修复版本。但这两种情况不太可能发生。

最有可能的原因是安全补丁无人值守升级。

解决此问题的一种方法是检查三件事：

查看日期：

$ ls -ltr /usr/bin/apt
-rwxr-xr-x 1 root root 18824 apr  8 12:22 /usr/bin/apt
rinzwind@discworld:~$ ls -ltr /usr/bin/curl
-rwxr-xr-x 1 root root 260328 mei  9 14:34 /usr/bin/curl
  • 荷兰月份 ;)
  • 所以 4 月 8 日是 apt
  • 5 月 9 日是 curl

检查版本/软件包

$ apt list apt
Listing... Done
apt/jammy,now 2.4.5 amd64 [installed,automatic]
apt/jammy 2.4.5 i386

和 ...

$ apt list curl
Listing... Done
curl/jammy-updates,jammy-security,now 7.81.0-1ubuntu1.2 amd64 [installed,automatic]
curl/jammy-updates,jammy-security 7.81.0-1ubuntu1.2 i386

检查命令的更改日志...

curl（7.81.0-1ubuntu1.2） jammy-security；紧急程度=中等

  • 安全更新：URL 主机中的百分比编码路径分隔符
    • debian/patches/CVE-2022-27780.patch：拒绝在 lib/urlapi.c 中将主机名百分比解码为分隔符字节。
    • CVE-2022-27780
  • 安全更新：CERTINFO 永无休止的繁忙循环
    • debian/patches/CVE-2022-27781.patch：如果似乎卡在 lib/vtls/nss.c 中的证书循环中，则返回错误。
    • CVE-2022-27781
  • 安全更新：TLS 和 SSH 连接过于急切地重用
    • debian/patches/CVE-2022-27782.patch：检查 lib/setopt.c、lib/url.c、lib/urldata.h、lib/vtls/gtls.c、lib/vtls/openssl.c、lib/vtls/nss.c、lib/vtls/vtls.c、lib/vssh/ssh.h 中的更多 TLS 详细信息，了解连接重用。
    • CVE-2022-27782

-- Marc Deslauriers 2022 年 5 月 9 日星期一 08:34:24 -0400

apt (2.4.5) 不稳定；紧急程度=中等

  • 仅保护两个内核，而不保护最后安装的内核（LP：#1968154）
  • 修复 CacheSetHelperAPTGet::tryVirtualPackage() 中的段错误

-- Julian Andres Klode 2022 年 4 月 8 日星期五 12:22:23 +0200

更新日志日期与我的可执行日期相匹配，因此对我来说，这是一个指标，表明一切都已检查完毕。我每天都会更新，而且我通常只使用受信任的存储库。

答案2

这个问题很傻，但其他人可能也有同样的问题。我启用了无人值守更新进行安全更新，如下所示

/etc/apt/apt.conf.d/50unattended-upgrades

包含行

"${distro_id}:${distro_codename}-security";

取消注释（等等）。对于所有意外更新的可执行文件，例如 bash，

apt list -a bash

显示安装的版本来自 -security 存储库。Rinzwind 的评论显示了可以验证这一点的其他方法。

相关内容