修补 CentOS 8 LUKS加密漏洞迫在眉睫

关注公众号回复“220127”获取“零信任框架设计原则”PDF版

依赖 CentOS 8 的组织用户面临遭受严重攻击的重大风险。安全机构新发现 LUKS 加密漏洞CVE-2021-4122，接下来根据国外安全网站报道讨论其缓解措施。

什么是LUKS？

那么什么是LUKS？LUKS 代表 Linux 统一密钥设置，是一种在 Linux 驱动的系统中使用的机制，用于支持全盘加密等。许多“最佳实践”指南都建议将其作为具有安全意识的 IT 团队的基本系统强化选项。

LUKS 是如何工作的？

在系统部署期间，可以使用用户提供的密码创建一个只能读取的分区——即其中的数据只能被理解。LUKS 相当复杂，许多安全系统都与 LUKS 交互，但全面的 LUKS 指南不是本文的目标。

拥有一个完全加密的磁盘（Linux 中的块设备“speak”）可确保数据即使在静止时也不会被窥探，这意味着例如窃取笔记本电脑的攻击者仍然无法查看包含在其中的机密数据。

可以通过 TPM（可信模块）将特定的设备绑定到特定的计算机，从而进一步建立安全性。这为攻击者增加了另一个障碍，使得从机器中物理提取加密数据并将其插入高性能系统以暴力访问数据变得更加困难。不过，和往常一样，成功的可能性有多大取决于计算能力、选择的加密算法，以及纯粹的运气。总体而言，LUKS 提供了出色的保护，因此，常被用来保护各种组织的系统。

了解 LUKS 缺陷

CVE-2021-4122 是在去年年底分配的，但直到最近才出现对 LUKS 周围安全风险的全面了解。事实证明，至少可以部分解密 LUKS 加密磁盘并访问其中的数据，而无需拥有用于配置加密的密码。

一个关键的 LUKS 功能是动态更改用于加密给定设备的密钥的能力。例如，可以在高安全性环境中为计划的密钥轮换执行此操作。

这种即时重新加密功能意味着设备在密钥更改过程中保持可用。被称为“在线重新加密”——指的是在磁盘在线和活动使用时使用不同的密钥重新加密磁盘的能力。

正是在这个过程中发现了一个漏洞。事实证明，如果知道自己在做什么，就可以在不拥有原始当前密码的情况下执行此操作。即使没有密码，也可以请求重新加密。

利用该漏洞，该过程似乎会被中止，并且某些数据将以未加密的形式提供。设备在任何时候都不会遇到任何异常行为，因此仅通过查看块设备状态很难发现攻击者正在执行操作。

强烈建议系统管理员在控制的所有系统上升级支持 LUKS 的软件包 cryptsetup，因为该漏洞可能导致信息泄露。

大多数供应商都对这个错误进行了早期警告，并且已经为他们的发行版提供了更新的软件包。支持 CentOS 的 Red Hat 也是如此。但是，由于 CentOS 8 现在不再受到官方支持，因此不会出现针对 LUKS 漏洞的 CentOS 8 补丁。

因此，对于 CentOS 8 用户来说，情况相当惨淡。由于已发布且广为人知的缺陷，未打补丁的系统很容易遭受数据盗窃。这是一种严重的情况，应该以一种或另一种方式部署受影响软件包的最新修补版本。

当机密数据面临风险时，不采取任何行动是不可行的。而且，从本质上讲，您的所有数据都是机密的，不能公开披露（否则它已经被公开了），并且完全依赖像 LUKS 这样的全盘加密解决方案来避免泄露。

使用 CentOS 8的组织迫切修补漏洞

依赖于在其生命周期结束后运行的受影响 Linux 系统的系统管理员可以使用两种途径。一种选择是下载上游项目源并在本地编译它，创建一个替换系统包。另一种选择是与扩展支持供应商签约，供应商将提供原始供应商不再发布的补丁。

本地构建方法有缺点。首先，原始项目源代码没有为特定分发做任何特殊考虑。每个发行版或发行系列都有自己的偏好。包括 CentOS 在内的 RHEL 家族也会有这些偏好。包括二进制位置、服务启动配置、设置等。当地的团队将不得不手动调整这些。当地的 IT 团队是否具备必要的专业知识是另一个问题。同样，由于技术团队通常面临完成任务的压力，因此 DIY 修补工作可能会被延迟。此外，在 LUKS 项目页面本身，有一个不祥的“请始终更喜欢发行版特定的构建工具而不是手动配置 cryptsetup”。

替代方案是将扩展支持供应商视为解决此问题的可靠、经济高效且更容易的方法。TuxCare 的延长生命周期支持服务就是这样做的。TuxCare 为 CentOS 8 等生命周期结束的发行版提供高质量的补丁，并且按时完成。更重要的是，可以获得对补丁的全面支持。部署很简单，可以像部署供应商支持的补丁一样轻松部署 TuxCare 补丁。

原文始发于微信公众号（祺印说信安）：修补 CentOS 8 LUKS加密漏洞迫在眉睫