主持人 > 之后有数百万个二进制文件。 Linux 如何变得更强大

之后有数百万个二进制文件。 Linux 如何变得更强大

之后有数百万个二进制文件。 Linux 如何变得更强大TL博士。 在本文中，我们将探讨在五个流行的 Linux 发行版上开箱即用的强化方案。 对于每个，我们采用默认的内核配置，加载所有包，并分析附加二进制文件中的安全方案。 考虑的发行版是 OpenSUSE 12.4、Debian 9、CentOS、RHEL 6.10 和 7，以及 Ubuntu 14.04、12.04 和 18.04 LTS。

结果证实，即使是堆栈金丝雀和位置无关代码等基本方案也尚未被所有人采用。 对于编译器来说，在防止堆栈冲突等漏洞方面，情况更糟，该漏洞在 XNUMX 月份发布后成为人们关注的焦点 有关 systemd 漏洞的信息。 但并非一切都那么无望。 大量二进制文件实现了基本的保护方法，并且其数量随着版本的不同而增长。

审查显示，Ubuntu 18.04 在操作系统和应用程序级别实现的保护方法数量最多，其次是 Debian 9。另一方面，OpenSUSE 12.4、CentOS 7 和 RHEL 7 也实现了基本的保护方案，以及堆栈碰撞保护通过更密集的默认包集使用得更广泛。

介绍

很难保证软件的高质量。 尽管有大量用于静态代码分析和动态运行时分析的先进工具，并且编译器和编程语言的开发取得了重大进展，但现代软件仍然存在不断被攻击者利用的漏洞。 在包含遗留代码的生态系统中，情况甚至更糟。 在这种情况下，我们不仅面临着寻找可能的可利用错误的永恒问题，而且还受到严格的向后兼容性框架的限制，这通常要求我们保留有限的，甚至更糟糕的易受攻击或有错误的代码。

这就是保护或强化程序的方法发挥作用的地方。 我们无法阻止某些类型的错误，但我们可以让攻击者的日子变得更加困难，并通过阻止或预防来部分解决问题 操作 这些错误。 所有现代操作系统都使用这种保护，但这些方法在复杂性、效率和性能方面差异很大：来自堆栈金丝雀和 ASLR 到全面保护 CFI и ROP。 在本文中，我们将了解最流行的 Linux 发行版在默认配置下使用的保护方法，并检查通过每个发行版的包管理系统分发的二进制文件的属性。

CVE 和安全性

我们都看过标题为“年度最脆弱的应用程序”或“最脆弱的操作系统”的文章。 通常他们提供有关漏洞的记录总数的统计数据，例如 CVE（常见漏洞和暴露）， 从...获取 国家漏洞数据库 (NVD) 从 NIST 和其他来源。 随后，这些应用程序或操作系统根据 CVE 的数量进行排名。 不幸的是，虽然 CVE 对于跟踪问题以及通知供应商和用户非常有用，但它们很少提及软件的实际安全性。

例如，考虑过去四年来 Linux 内核和五个最流行的服务器发行版（即 Ubuntu、Debian、Red Hat Enterprise Linux 和 OpenSUSE）的 CVE 总数。

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 1

这张图告诉我们什么？ CVE 数量较多是否意味着一种发行版比另一种发行版更容易受到攻击？ 没有答案。 例如，在本文中，您将看到 Debian 比 OpenSUSE 或 RedHat Linux 等具有更强的安全机制，而且 Debian 拥有更多的 CVE。 然而，它们并不一定意味着安全性减弱：即使存在 CVE 也并不表明漏洞是否存在 被剥削。 严重性分数表明了如何 大概 漏洞的利用，但最终的可利用性在很大程度上取决于受影响系统中的保护以及攻击者的资源和能力。 此外，缺乏 CVE 报告并不能说明其他问题 未注册或未知 漏洞。 CVE 的差异可能是由于软件质量以外的因素造成的，包括分配给测试的资源或用户群的规模。 在我们的示例中，Debian 的 CVE 数量较多可能只是表明 Debian 发布了更多的软件包。

当然，CVE 系统提供了有用的信息，允许您创建适当的保护。 我们越了解程序失败的原因，就越容易识别可能的利用方法并开发适当的机制 检测和响应。 在图中。 图 2 显示了过去四年中所有发行版的漏洞类别（源）。 显而易见，大多数 CVE 属于以下类别：拒绝服务 (DoS)、代码执行、溢出、内存损坏、信息泄漏（渗透）和权限升级。 尽管许多 CVE 在不同类别中被多次计算，但总的来说，相同的问题年复一年地持续存在。 在本文的下一部分中，我们将评估使用各种保护方案来防止这些漏洞被利用。

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 2

任务

在本文中，我们打算回答以下问题：

  • 不同Linux发行版的安全性如何？ 内核和用户空间应用程序存在哪些保护机制？
  • 随着时间的推移，各个发行版的安全机制的采用发生了怎样的变化？
  • 每个发行版的包和库的平均依赖性是多少？
  • 每个二进制文件实施了哪些保护？

分布的选择

事实证明，很难找到有关发行版安装的准确统计数据，因为在大多数情况下，下载数量并不表示实际安装数量。 然而，Unix 变体构成了大多数服务器系统（在 Web 服务器上占 69,2%，按 统计 W3techs 和其他来源），并且他们的份额正在不断增长。 因此，在我们的研究中，我们重点关注平台上开箱即用的发行版 谷歌云。 我们特别选择了以下操作系统：

发行版/版本
核心
建造

OpenSUSE 12.4
4.12.14-95.3-默认
#1 SMP 5 年 06 月 00 日星期三 48:2018:63 UTC 8 (29aXNUMXdXNUMX)

Debian 9（延伸）
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10的
2.6.32-754.10.1.el6.x86_64
#1 SMP 15 年 17 月 07 日星期二 28:2019:XNUMX UTC

CentOS 7的
3.10.0-957.5.1.el7.x86_64
#1 SMP 1 年 14 月 54 日星期五 57:2019:XNUMX UTC XNUMX

红帽企业 Linux 服务器 6.10（圣地亚哥）
2.6.32-754.9.1.el6.x86_64
#1 SMP 21 年 15 月 08 日星期三 21:2018:XNUMX 美国东部时间

红帽企业 Linux 服务器 7.6（麦坡）
3.10.0-957.1.3.el7.x86_64
#1 SMP 15 年 17 月 36 日星期四 42:2018:XNUMX UTC

Ubuntu 14.04（值得信赖的塔尔）
4.4.0–140-通用

#166~14.04.1-Ubuntu SMP 17 月 01 日星期六 52:43:20 UTC XNUMX…

Ubuntu 16.04（Xenial Xerus）
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7 年 09 月 59 日星期五 47:2018:XNUMX UTC

Ubuntu 18.04（仿生海狸）
4.15.0–1026-gcp
#27-Ubuntu SMP 6 年 18 月 27 日星期四 01:2018:XNUMX UTC

表1

分析

让我们研究默认的内核配置，以及通过每个发行版的包管理器可用的包的属性。 因此，我们只考虑每个发行版默认镜像中的软件包，忽略来自不稳定存储库的软件包（例如 Debian“测试”镜像）和第三方软件包（例如来自标准镜像的 Nvidia 软件包）。 此外，我们不考虑自定义内核编译或安全强化配置。

内核配置分析

我们应用了基于的分析脚本 免费的 kconfig 检查器。 让我们看看指定发行版的开箱即用保护参数，并将它们与来自的列表进行比较 核心自卫项目 （KSPP）。 对于每个配置选项，表 2 描述了所需的设置：该复选框适用于符合 KSSP 建议的发行版（有关术语的解释，请参阅以下内容）。 这里; 在以后的文章中，我们将解释这些安全方法有多少种，以及在没有这些方法的情况下如何破解系统）。

之后有数百万个二进制文件。 Linux 如何变得更强大

之后有数百万个二进制文件。 Linux 如何变得更强大

一般来说，新内核具有更严格的开箱即用设置。 例如，6.10 内核上的 CentOS 6.10 和 RHEL 2.6.32 缺乏较新内核中实现的大部分关键功能，例如 SMAP、严格的RWX权限、地址随机化或copy2usr保护。 需要注意的是，表中的许多配置选项在旧版本的内核中不可用，并且在现实中不适用——这在表中仍然表明缺乏适当的保护。 同样，如果给定版本中不存在配置选项，并且安全性要求禁用该选项，则这被认为是合理的配置。

解释结果时要考虑的另一点是：一些增加攻击面的内核配置也可用于安全性。 此类示例包括 uprobes 和 kprobes、内核模块以及 BPF/eBPF。 我们的建议是使用上述机制来提供真正的保护，因为它们使用起来并不简单，并且它们的利用假设恶意行为者已经在系统中建立了立足点。 但如果启用这些选项，系统管理员必须主动监控滥用情况。

进一步查看表 2 中的条目，我们发现现代内核提供了多种选项来防止利用漏洞，例如信息泄漏和堆栈/堆溢出。 然而，我们注意到，即使是最近流行的发行版也尚未实现更复杂的保护（例如，使用补丁 安全）或针对代码重用攻击的现代保护（例如 随机化与代码 R^X 等方案的组合）。 更糟糕的是，即使这些更先进的防御措施也无法抵御全方位的攻击。 因此，系统管理员必须通过提供运行时漏洞检测和预防的解决方案来补充智能配置。

应用分析

毫不奇怪，不同的发行版具有不同的包特征、编译选项、库依赖关系等。甚至对于 有关 具有少量依赖项的发行版和软件包（例如 Ubuntu 或 Debian 上的 coreutils）。 为了评估差异，我们下载了所有可用的软件包，提取其内容，并分析了二进制文件和依赖项。 对于每个包，我们跟踪它所依赖的其他包，对于每个二进制文件，我们跟踪它的依赖项。 在本节中，我们简要总结了结论。

发行版

我们总共为所有发行版下载了 361 个软件包，仅从默认镜像中提取软件包。 我们忽略了没有 ELF 可执行文件的包，例如源代码、字体等。过滤后，剩下 556 个包，总共包含 129 个二进制文件。 各个发行版中包和文件的分布如图 569 所示。 584.

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 3

您可能会注意到，发行版越现代，它包含的包和二进制文件就越多，这是合乎逻辑的。 然而，Ubuntu 和 Debian 软件包比 CentOS、SUSE 和 RHEL 包含更多的二进制文件（包括可执行文件和动态模块和库），这可能会影响 Ubuntu 和 Debian 的攻击面（应该注意的是，这些数字反映了所有版本的所有二进制文件）包，即某些文件被分析多次）。 当您考虑包之间的依赖关系时，这一点尤其重要。 因此，单个包二进制文件中的漏洞可能会影响生态系统的许多部分，就像易受攻击的库可能会影响导入它的所有二进制文件一样。 首先，让我们看看不同操作系统中包之间的依赖关系数量分布：

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 4

在几乎所有发行版中，60% 的包至少有 10 个依赖项。 此外，某些包的依赖项数量明显较多（超过 100 个）。 这同样适用于反向包依赖性：正如预期的那样，发行版中的许多其他包使用了一些包，因此这些选定的少数包中的漏洞风险很高。 例如，下表列出了 SLES、Centos 20、Debian 7 和 Ubuntu 9 中反向依赖数量最多的 18.04 个软件包（每个单元格表示软件包和反向依赖数量）。

之后有数百万个二进制文件。 Linux 如何变得更强大
表3

有趣的事实。 尽管分析的所有操作系统都是针对 x86_64 架构构建的，并且大多数软件包都将架构定义为 x86_64 和 x86，但软件包通常包含其他架构的二进制文件，如图 5 所示。 XNUMX.

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 5

在下一节中，我们将深入研究所分析的二进制文件的特征。

二进制文件保护统计

至少，您需要为现有的二进制文件探索一组基本的安全选项。 一些 Linux 发行版附带了执行此类检查的脚本。 例如Debian/Ubuntu就有这样的脚本。 这是他的工作示例：

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

该脚本检查五个 保护功能:

  • 位置无关可执行文件 (PIE)：指示如果在内核中启用 ASLR，是否可以在内存中移动程序的文本部分以实现随机化。
  • 堆栈保护：是否启用堆栈金丝雀以防止堆栈冲突攻击。
  • Fortify Source：不安全函数（例如，strcpy）是否替换为更安全的对应函数，运行时检查的调用是否替换为其未检查的对应函数（例如，memcpy 而不是 __memcpy_chk）。
  • 只读重定位 (RELRO)：如果在执行开始之前触发重定位表条目，是否将其标记为只读。
  • 立即绑定：运行时链接器是否允许在程序执行开始之前进行所有移动（这相当于完​​整的 RELRO）。

上述机制是否足够？ 很不幸的是，不行。 有一些已知的方法可以绕过上述所有防御，但防御越严格，攻击者的门槛就越高。 例如， RELRO绕过方法 如果 PIE 和立即绑定生效，则应用起来会更加困难。 同样，完整的 ASLR 需要额外的工作来创建有效的漏洞利用。 然而，老练的攻击者已经准备好满足此类保护：他们的缺席将本质上加速黑客攻击。 因此，这些措施必须被认为是必要的 最低限度.

我们想要研究相关发行版中有多少二进制文件受到这些方法和其他三种方法的保护：

  • 不可执行位（NX) 阻止在任何不应执行的区域执行，例如堆栈堆等。
  • R路径/运行路径 表示动态加载器用来查找匹配库的执行路径。 第一个是 义务 对于任何现代系统：它的缺失允许攻击者任意将有效负载写入内存并按原样执行。 对于第二个，不正确的执行路径配置有助于引入不可靠的代码，从而导致许多问题（例如 特权升级和 其他问题).
  • 堆栈冲突保护可防止导致堆栈与其他内存区域（例如堆）重叠的攻击。 鉴于最近的滥用行为 systemd 堆冲突漏洞，我们认为将该机制包含在我们的数据集中是合适的。

因此，事不宜迟，让我们开始讨论数字。 表 4 和表 5 分别包含对各种发行版的可执行文件和库的分析摘要。

  • 如您所见，除了极少数例外，NX 保护随处可见。 特别是，与 CentOS、RHEL 和 OpenSUSE 相比，它在 Ubuntu 和 Debian 发行版中的使用率略低。
  • 堆栈金丝雀在许多地方都缺失，特别是在具有较旧内核的发行版中。 Centos、RHEL、Debian 和 Ubuntu 的最新发行版中已经看到了一些进展。
  • 除了 Debian 和 Ubuntu 18.04 之外，大多数发行版对 PIE 的支持都很差。
  • OpenSUSE、Centos 7 和 RHEL 7 中的堆栈冲突保护很弱，而在其他操作系统中几乎不存在。
  • 所有具有现代内核的发行版都对 RELRO 提供一定的支持，其中 Ubuntu 18.04 领先，Debian 紧随其后。

如前所述，此表中的指标是二进制文件所有版本的平均值。 如果您只查看文件的最新版本，数字将会不同（例如，请参阅 Debian 在 PIE 实施方面取得进展）。 此外，大多数发行版在计算统计数据时通常只测试二进制文件中少数函数的安全性，但我们的分析显示了经过强化的函数的真实百分比。 因此，如果二进制文件中的 5 个功能中有 50 个受到保护，我们会给它打 0,1 分，这对应于 10% 的功能得到加强。

之后有数百万个二进制文件。 Linux 如何变得更强大
表 4. 图 3 所示可执行文件的安全特性XNUMX（相关功能的实现占可执行文件总数的百分比）

之后有数百万个二进制文件。 Linux 如何变得更强大
表 5. 图 3 所示库的安全特性XNUMX（相关功能实现量占库总数的百分比）

那么有进展吗？ 肯定有：这可以从各个分布的统计数据中看出（例如， Debian）以及上表中的结果。 如图所示。 图 6 显示了 Ubuntu LTS 5 三个连续发行版中保护机制的实现（我们省略了堆栈冲突保护统计）。 我们注意到，从一个版本到另一个版本，越来越多的文件支持堆栈金丝雀，并且越来越多的二进制文件附带了完整的 RELRO 保护。

之后有数百万个二进制文件。 Linux 如何变得更强大
图。 6

不幸的是，不同发行版中的许多可执行文件仍然没有任何上述保护。 例如，查看 Ubuntu 18.04，您会注意到 ngetty 二进制文件（getty 的替代品）、mksh 和 lksh shell、picolisp 解释器、nvidia-cuda-toolkit 软件包（GPU 加速应用程序的流行软件包）例如机器学习框架）和 klibc -utils。 同样，mandos-client 二进制文件（一种管理工具，允许您自动重新启动具有加密文件系统的计算机）以及 rsh-redone-client（rsh 和 rlogin 的重新实现）在发布时没有 NX 保护，尽管它们具有 SUID 权限： （此外，一些 suid 二进制文件缺乏基本的保护，例如堆栈金丝雀（例如，Xorg 包中的 Xorg.wrap 二进制文件）。

总结和结束语

在本文中，我们重点介绍了现代 Linux 发行版的几个安全功能。 分析表明，平均而言，最新的 Ubuntu LTS 发行版 (18.04) 在具有相对较新内核的发行版（例如 Ubuntu 14.04、12.04 和 Debian 9）中实现了最强的操作系统和应用程序级别保护。然而，所检查的发行版 CentOS、RHEL 和默认情况下，我们的集合中的 OpenSUSE 会生成一组更密集的软件包，并且在最新版本（CentOS 和 RHEL）中，与基于 Debian 的竞争对手（Debian 和 Ubuntu）相比，它们具有更高百分比的堆栈冲突保护。 比较 CentOS 和 RedHat 版本，我们注意到从版本 6 到版本 7，堆栈金丝雀和 RELRO 的实现有了很大改进，但平均而言，CentOS 比 RHEL 实现了更多功能。 一般来说，所有发行版都应特别注意 PIE 保护，除了 Debian 9 和 Ubuntu 18.04 之外，我们数据集中不到 10% 的二进制文件实现了 PIE 保护。

最后，应该指出的是，虽然我们手动进行研究，但有许多可用的安全工具（例如 Lynis, 虎, 哈勃），它执行分析并帮助避免不安全的配置。 不幸的是，即使配置合理的强大保护也不能保证不被利用。 这就是为什么我们坚信，确保 实时可靠地监控和预防攻击，重点关注剥削模式并加以预防。

来源： habr.com

添加评论