Geekly articles weekly

数百万的二进制文件。 Linux如何得到加强

TL； DR 。 在本文中，我们探索了可在五种流行的Linux发行版上立即使用的强化方案。 对于每一个，我们采用默认的内核配置，下载了所有软件包，并分析了随附的二进制文件中的保护方案。 我们考虑了OpenSUSE 12.4，Debian 9，CentOS，RHEL 6.10和7以及Ubuntu 14.04、12.04和18.04 LTS的发行版。

结果证实，甚至每个人都尚未使用基本方案，例如堆栈金丝雀和与位置无关的代码。 对于防止诸如堆栈冲突之类的漏洞的情况，编译器的情况甚至更糟。该漏洞在systemd中发布漏洞信息后于一月份引起了人们的关注。 但是，并非一切都如此无望。 在二进制文件的很大一部分中，实现了基本的保护方法，并且它们的版本在不断增加。

验证显示，在操作系统和应用程序级别上，Ubuntu 18.04实施了最多数量的保护方法，其次是Debian9。另一方面，在OpenSUSE 12.4，CentOS 7和RHEL 7中，还实现了基本的保护方案，并且针对堆栈冲突的保护得到了更广泛的应用。默认情况下具有更密集的一组软件包。

引言


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

这是硬化方法起作用的地方。 我们无法防止某些类型的错误，但可以通过防止或阻止这些错误的操作使攻击者的生活更加困难，并部分解决问题。 在所有现代操作系统中都使用了这种保护，但是，这些方法的复杂性，效率和性能差异很大：从堆栈金丝雀和ASLR到成熟的CFI和ROP保护。 在本文中，我们将考虑在默认配置下最流行的Linux发行版中使用了哪些保护方法，还将研究通过每个发行版的程序包管理系统发行的二进制文件的属性。

CVE和安全性


我们都看过标题为“年度最易受攻击的应用程序”或“最易受攻击的操作系统”的文章。 通常，它们提供有关漏洞记录总数的统计信息，例如从NIST和其他来源的国家漏洞数据库（NVD）获得的CVE（常见漏洞和披露） 。 随后，这些应用程序或操作系统按CVE的数量排名。 不幸的是，尽管CVE对于跟踪问题并通知供应商和用户非常有用，但它们对软件的真正安全性知之甚少。

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


图 1个

这张图告诉我们什么？ 更多的CVE是否意味着一个发行版比另一个发行版更容易受到攻击？ 没有答案。 例如，在本文中，您将看到Debian实现了比OpenSUSE或RedHat Linux更严格的安全性机制，而D​​ebian具有更多的CVE。 但是，它们并不一定意味着安全性减弱：即使拥有CVE也无法说明该漏洞是否可利用 。 严重程度得分给出了利用漏洞的可能性的想法，但是最终利用程度在很大程度上取决于受影响系统中存在的保护以及攻击者的资源和能力。 此外，缺少CVE报告并没有说明其他未注册或未知的漏洞。 CVE的差异不能用软件质量来解释，而可以用其他因素来解释，包括分配给测试的资源或用户群的大小。 在我们的示例中，更多的Debian CVE可能只是表明Debian正在交付更多的软件包。

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


图 2

任务


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

  • 各种Linux发行版的安全性是什么？ 内核和用户空间应用程序中存在哪些防御机制？
  • 随着时间的流逝，对各种发行版采用保护机制有何变化？
  • 每种发行版的软件包和库的平均依赖性是什么？
  • 每个二进制文件实现了哪些保护？

选择分布


事实证明，很难找到有关发行版安装的准确统计信息，因为在大多数情况下，下载数量并不表示实际安装的数量。 但是，Unix变体构成了大多数服务器系统（根据W3techs和其他来源的统计，在Web服务器上占69.2％），并且它们的份额还在不断增长。 因此，在我们的研究中，我们重点研究了Google Cloud平台上可用的现成发行版。 特别是，我们选择了以下操作系统：

发行/版本核心建立
OpenSUSE 12.44.12.14-95.3-默认＃1 SMP 2018年12月5日星期三06:00:48 UTC（63a8d29）
Debian 9（伸展）4.9.0-8-amd64＃1 SMP Debian 4.9.130-2（2018-10-27）
CentOS的6.102.6.32-754.10.1.el6.x86_64＃1 SMP 2019年1月15日星期二17:07:28
CentOS的73.10.0-957.5.1.el7.x86_64＃1 SMP星期五2月1日14:54:57 UTC 2019
红帽企业Linux服务器6.10（圣地亚哥）2.6.32-754.9.1.el6.x86_64＃1 SMP 2018年11月21日星期三15:08:21
红帽企业版Linux Server 7.6（Maipo）3.10.0-957.1.3.el7.x86_64＃1 SMP 2018年11月15日星期四17:36:42
Ubuntu 14.04（Trusty Tahr）4.4.0–140通用
＃166〜04/14 / 1-Ubuntu SMP星期六11月17日01:52:43 UTC 20 ...
Ubuntu 16.04（Xenial Xerus）4.15.0-1026-gcp＃27〜16.04.1-Ubuntu SMP 2018年12月7日星期五09:59:47 UTC
Ubuntu 18.04（仿生海狸）4.15.0-1026-gcp＃27-Ubuntu SMP 2018年12月6日星期四18:27:01
表1

分析方法


我们将检查默认的内核配置以及开箱即用的每个分发软件包的软件包管理器提供的软件包属性。 因此，我们仅考虑每个发行版的默认镜像中的软件包，而忽略不稳定存储库中的软件包（例如Debian中的“测试”镜像）和第三方软件包（例如，标准镜像中的Nvidia软件包）。 此外，我们不考虑自定义内核编译或高级安全性配置。

内核配置分析


我们使用了基于免费的kconfig checker的分析脚本。 我们考虑了针对指定发行版的开箱即用的保护选项，并将它们与内核自防御项目 （KSPP）中的列表进行比较。 对于每个配置参数，表2描述了所需的设置：复选标记用于符合KSSP建议的发行版（有关术语的说明，请参见此处 ;在以后的文章中，我们将描述出现了多少种这种保护方法以及如何在没有这种保护方法的情况下对系统进行破解）。





通常，较新的内核具有更严格的设置。 例如，2.6.32内核上的CentOS 6.10和RHEL 6.10没有在新内核中实现的大多数关键功能，例如SMAP ，强大的RWX权限，地址随机化或copy2usr保护。 应该注意的是，表的许多配置选项在较早版本的内核中是不存在的，实际上并不适用-在表中仍然指出这是缺乏适当的保护。 同样，如果该配置参数在此版本中不可用，并且出于安全性考虑，必须禁用此参数，则认为这是合理的配置。

解释结果时的另一点：可以同时使用某些增加攻击面的内核配置来提高安全性。 这样的例子包括uprobes和kprobes，内核模块以及BPF / eBPF。 我们的建议是使用上述机制来提供真正的保护，因为它们并非微不足道，并且其操作假定恶意行为者已经在系统中根深蒂固。 但是，如果启用了这些选项，则系统管理员必须主动监视滥用情况。

进一步研究表2中的条目，我们看到现代内核提供了几种选项来防止利用诸如信息泄漏和堆栈/堆溢出之类的漏洞。 但是，我们注意到，即使是最近流行的发行版也尚未实现更复杂的保护（例如，使用grsecurity补丁程序）或现代保护，以防止代码重用攻击（例如， 将随机化与类似R ^ X的方案结合用于代码 ）。 更糟糕的是，即使这些更高级的防御措施也无法防御各种攻击。 因此，对于系统管理员而言，至关重要的是要通过在运行时提供检测和防止漏洞利用的解决方案来补充智能配置。

应用分析


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

发行版


我们总共为所有发行版下载了361,556个软件包，仅从默认镜像中提取了软件包。 我们忽略了没有ELF可执行文件（例如源代码，字体等）的软件包。过滤后，剩下129569个软件包，其中总共包含584457个二进制文件。 包和文件在各发行版之间的分配如图2所示。 3。


图 3

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


图 4

在几乎所有发行版中，60％的软件包至少具有10个依赖项。 此外，某些软件包具有更多的依赖项（超过100个）。 反向程序包的依赖关系也是如此：正如预期的那样，发行版中的许多其他程序包都使用了多个程序包，因此，这几个收藏夹中的漏洞具有很高的风险。 例如，下表列出了20个软件包，它们在SLES，Centos 7，Debian 9和Ubuntu 18.04中具有最大的逆相关性（每个框表示软件包和逆相关性的数量）。


表3

一个有趣的事实。 尽管所有已分析的OS都是针对x86_64体系结构构建的，但大多数软件包的体系结构均定义为x86_64和x86，但软件包通常包含其他体系结构的二进制文件，如图2所示。 5，


图 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）。

以上机制够吗？ 不幸的是，没有。 有已知的方法可以绕过上述所有防御措施，但是防御措施越严格，攻击者的标准就越高。 例如，如果PIE和立即绑定有效，则RELRO解决方法将难以应用。 同样，完整的ASLR需要额外的工作才能创建有效的利用程序。 但是，老练的攻击者已准备好应对这种防御措施：他们的缺席将在本质上加速黑客攻击。 因此，必须将这些措施视为必要的最低限度 。

我们想研究这些发行版中有多少二进制文件受这些保护，以及另外三种方法：

  • 不可执行位（ NX ）阻止在不应执行的任何区域（例如堆栈堆等）中执行。
  • RPATH / RUNPATH指示动态加载程序用来查找适当库的执行路径。 第一个对于任何现代系统都是必需的：它的缺失使攻击者可以将有效载荷任意写入内存并按原样执行。 第二，执行路径的错误配置有助于引入不受信任的代码，这可能导致许多问题（例如， 特权升级以及其他问题 ）。
  • 堆栈冲突保护提供了针对导致堆栈与其他内存区域（例如堆）重叠的攻击的保护。 鉴于最近利用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实现进度 ）。 此外，大多数分布通常在计算统计信息时检查二进制代码中只有少数几个功能的保护，而在我们的分析中，指出了增强功能的真实百分比。 因此，如果二进制文件中有50个功能中有5个受到保护，我们将其定为0.1，相当于增强功能的10％。


表4.图11所示的可执行文件的保护特性 3（相应功能的实现占可执行文件总数的百分比）


表5.图11中所示库的保护特性 3（相应功能的实现占库总数的百分比）

那么有进步吗？ 绝对有：从单个发行版的统计信息（例如Debian ）以及上表中可以看出。 作为图的一个例子。 图6显示了三个连续的Ubuntu LTS 5发行版中的防御机制的实现（我们省略了堆栈冲突保护统计信息）。 我们注意到，从一个版本到另一个版本，越来越多的文件支持堆叠的金丝雀，并且依次地，越来越多的二进制文件具有完整的RELRO保护。


图 6

不幸的是，不同发行版中的许多可执行文件仍然没有上述任何保护。 例如，查看Ubuntu 18.04，您会看到ngetty二进制文件（getty替换），以及mksh和lksh shell，picolisp解释器，nvidia-cuda-toolkit软件包（用于GPU加速应用程序的流行软件包，例如机器学习框架）和klibc。 -utils。 同样，尽管mandos-client二进制文件（使您可以自动重启带有加密文件系统的计算机的管理工具）以及rsh-redone-client（重新实现rsh和rlogin），但它们都具有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以外，PIE保护是在数据集中不到10％的二进制文件中实现的。

最后，应该注意：尽管我们是手动进行研究的，但仍有许多安全工具（例如Lynis ， Tiger ， Hubble ）可以执行分析并帮助避免不安全的配置。 不幸的是，即使在合理配置下提供强有力的保护也不能保证没有漏洞利用。 因此，我们坚信至关重要的是，确保实时可靠地监视和预防攻击 ，重点是运行模型并加以预防。

Source: https://habr.com/ru/post/zh-CN444418/

More articles:


All Articles