![什么(除软件更新之外)可以更新系统可执行文件?](https://linux22.com/image/1187325/%E4%BB%80%E4%B9%88%EF%BC%88%E9%99%A4%E8%BD%AF%E4%BB%B6%E6%9B%B4%E6%96%B0%E4%B9%8B%E5%A4%96%EF%BC%89%E5%8F%AF%E4%BB%A5%E6%9B%B4%E6%96%B0%E7%B3%BB%E7%BB%9F%E5%8F%AF%E6%89%A7%E8%A1%8C%E6%96%87%E4%BB%B6%EF%BC%9F.png)
当软件更新程序弹出一些要安装的更新时,我会在应用它们之前运行 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 的评论显示了可以验证这一点的其他方法。