Translated message

A translation of this page exists in English.

有关如何处理漏洞扫描的教程

已更新 -

介绍

与过去相比,现在安全考虑更加重要。我们每天都发现影响我们计算机系统的新漏洞,它们变得更加复杂。

解释并解决漏洞扫描中发现的威胁的过程通常看起来很复杂。具有大量发现的扫描结果可能比具有少量发现的扫描更准确,但情况并非总是如此。 真正准确的扫描将删除重复的数据,使用厂商披露的数据,并协助安全专业人员优先消除风险。

误报、漏报和数据差异是漏洞扫描难以比较和理解的主要原因。随着软件复杂性的增加,这些原因被夸大了。最佳示例是像 Red Hat OpenShift 那样的容器化环境,除了容器的首要内容之外,它还打包并包含了平台依赖项。

本文档旨在帮助客户更好地了解术语、概念和行业相关实践,以便在进行漏洞扫描后优先进行风险评估。

理解术语

受影响的
这只是一个“是”或“否”的决定,以指示是否存在易受攻击的代码。如果漏洞代码无法或不会被执行,则这无关紧要。如果存在,则我们认为组件受到了影响。

影响的

如果对信息安全三要素中的任何一个:机密性、完整性和可用性(CIA)产生影响,则认为受影响的组件受到了漏洞的影响。
在某些情况下,有漏洞的工件/代码在组件或产品中无法被利用时,受影响的组件不会受到漏洞的影响。因此,对 CIA 没有影响。

严重性评级

红帽产品安全团队使用四分制(低、中等、重要和严重)对红帽产品中发现的安全问题 进行严重性评级。红帽严重性评级旨在针对红帽构建、发布和配置代码提供一个优先的风险评估,并协助安排升级。此评级并不是作为与 CVSS 的直接关联派生而来的。这意味着,我们的评级有时会与 NVD 不同,具体取决于我们的软件是如何构建和部署的。

NVD 可能会将特定服务中的一个缺陷评级为对 CVSS CIA 三要素 (机密性, 完整性, 可用性)具有重大影响,其中有问题的服务通常在系统上以具有完全特权的 root 用户身份运行。但是,在红帽产品中,服务可能被专门配置为作为完全在 SELinux 沙盒中运行的专用的非特权用户的身份来运行,这大大减少了威胁带来的直接影响,从而导致低影响。建议在扫描红帽产品时始终使用红帽严重性。

CVSS 分数

红帽使用 CVSS 基本指标 来说明特定的漏洞是如何工作的,以及信息安全三要素 — 机密性、完整性和可用性(CIA)的哪个方面受到了漏洞的影响。CVSS 基本指标不是风险的衡量,应是与其他时间和环境指标一起计算而来的。对于由多个供应商提供的开源软件,CVSS 基础分数可能会因 每个供应商的版本而有所不同,具体取决于他们提供的版本、提供的方式、平台,甚至软件的编译方式。这些依赖项使得第三方漏洞数据库(如 NVD,其对每个漏洞只提供一个 CVSS 基础分数)很难对漏洞进行评分。红帽分数反映了漏洞如何具体影响我们的产品。

风险和优先级

漏洞扫描的消费者应在他们自己的风险评估中结合使用红帽严重性评级(风险优先级)和 CVSS 分数(基础+时间+环境)来对优先级做出正确的判断。在不同的环境中,一个漏洞的风险可能有所不同。当 容器化环境 可能根本无法利用时,标准裸机系统中同样的漏洞可能具有很高的严重性。因此,风险降至最低。红帽工程团队使用我们的严重性评级来确定补丁的优先级,这解释了为什么低和中等级别的 CVE 不能像关键和重要的 CVE 那样被快速解决。

扫描的工件与父软件包

安全扫描程序通常会提供有关检测到的漏洞的工件(可能是一个库或模块)的信息,但是,检查提供该工件的软件包通常是至关重要的。在一个 rpm 软件包中,它可以包含多个库或模块的捆绑包。当其中一个模块存在漏洞时,补丁会以新的主 rpm 软件包版本(或新的容器镜像)的形式提供。红帽不提供带有安全修复的单个模块或库。这就是为什么源 rpm (或容器镜像)的知识非常重要的原因。有关 rpm 软件包的详情,请参阅 https://access.redhat.com/solutions/6002741

版本和反向移植

为了保持代码的稳定性和兼容性,红帽通常不会将软件包更新为一个全新的版本。相反,我们会将修复和新功能反向移植 到我们已发布的一个旧版本中。这可能会导致一些只考虑软件包版本的安全扫描程序报告软件包存在漏洞,从而导致非常不同的响应和工作优先级。

红帽安全公告(RHSA)

红帽发布多种形式的 公告 。每当对产品的更新包含安全修复时,红帽都会发布 安全公告 (RHSA)。任何 RHSA 都可以包括对多个 CVE 的修复,因此,始终继承被纠正的 CVE 的最高红帽严重性评级。许多漏洞扫描程序都使用 RHSA 数据来确定是否解决了漏洞,这种决定可能是不完美的。在某些情况下,分层产品或服务可使用传统的 bug 公告(RHBA)中的平台安全修复。

红帽漏洞数据

所有与影响红帽产品组合的漏洞有关的 数据 (受影响的状态、受影响的产品、分数和评级)都会在公开披露漏洞后公开提供。我们以以下行业标准的人类和机器可读的格式发布我们的数据:

每一种披露格式都有利有弊,如果没有正确解释和综合利用,后者会产生误报的可能。例如,OVAL 只处理打包为 RPM 的组件的漏洞。

修复识别的漏洞的推荐流程

删除重复和误报

可以使用几种方法来过滤和优先排序发现。每种方法的解释如下。

  1. 研究并了解每个报告的漏洞。

    示例:CVE-2018-20225 - python-pip
    包括红帽在内的许多供应商都不认为该漏洞是一个真正的漏洞,如 红帽 CVE 页面 上的声明部分所示:尽管此问题影响了随 Red Hat-Enterprise Linux 一起发布的 pip 版本,Red Hat Software Collections
    和 Red Hat CodeReady Workspaces,但红帽产品安全团队不会将此漏洞视为一个安全漏洞,因为根据 pip 文档,这是 pip 在使用 --extra-index-url 标志时的预期行为。因此,这个问题被标记为 WONTFIX "。

  2. 了解报告的有漏洞的工件。

    • 如果报告的有漏洞的工件是一个 rpm 软件包,您可以将检测的 rpm 软件包版本与有漏洞的软件包版本进行比较。安全扫描程序经常匹配不正确的版本,已经修复的版本会被报告为有漏洞。

      示例:CVE-2005-2541 - 1.15.1 以下的 tar 软件包存在漏洞,但在 [rhel8/postgresql-10:1-192]
      (https://catalog.redhat.com/software/containers/rhel8/postgresql-10/5ba0ae0ddd19c70b45cbf4cd?container-tabs=packages)镜像中,发布的 tar 版本为 1.30-5,它是 tar 软件包的更新和固定版本,即使最初红帽对这个漏洞的决策是"不会修复",因为与该漏洞相关的风险很低。

    • 如果报告的工件看起来像一个模块或库,根据工件路径检查此工件的源 rpm 软件包。您可以在以下解决方案中找到有关如何进行此操作的信息:https://access.redhat.com/solutions/6002741

      当您知道准确的源 rpm 时,您可以检查 Red Hat CVE 页面以了解特定报告的漏洞,并查找在其中捆绑了检测到的工件的 rpm 软件包的信息。

      示例:CVE-2020-2134 - Jenkins 脚本安全插件 1.70 的 Sandbox 保护,早期版本存在漏洞。
      例如,当您对 openshift4/ose-jenkins 容器镜像执行安全扫描时,像 org.kohsuke:groovy-sandbox:1.16 这样的路径可能会被错误地标记为存在漏洞。在检查时会发现 Jenkins 脚本安全插件捆绑在jenkins-2-plugin rpm 软件包中,且此 CVE 已在 OpenShift 4.4 和 4.3 中被修复:
      https://access.redhat.com/errata/RHSA-2020:3616
      https://access.redhat.com/errata/RHSA-2020:2737

  3. 假设报告的构件看起来像一个模块或库,并且确认其与任何安装的软件包没有关联。在这种情况下,这是可能出现在容器第一个构建中的非 rpm 内容。
    在这种情况下,如果报告的有漏洞的容器是原始的红帽容器镜像,则您应该在 Red Hat CVE 页面上检查特定容器的确切名称。

    示例:CVE-2021-44716
    如果扫描报告指出 openshift4/ose-jenkins 容器镜像受到了此漏洞的影响,则您可以检查 Red Hat CVE 页面,并在受影响的产品及其组件列表中查找 openshift4/ose-jenkins 容器,您会发现 openshift4/ose-jenkins 容器已在 OpenShift 4.10.3 中被修复:https://access.redhat.com/errata/RHSA-2022:0056

  4. 如果对带有许多容器(如 OpenShift Container Platform)的容器化产品执行漏洞扫描,并且检测到的 CVE 与像 Golang 这样的编程语言的标准库相关,则请检查 Red Hat CVE 页面声明,因为有时平台产品不会受到非常常见的漏洞的影响,如 CVE-2021-38297。在声明部分中,您可以找到以下信息:
    "CVE-2021-38297 不会影响 OpenShift Container Platform (OCP),因为它没有使用 GOARCH=wasm GOOS=js 构建任何东西。因此,基于 OCP 的服务也不会受到影响"。

  5. 检查扫描程序界面以得到源产品信息。认证的安全扫描程序有时提供与红帽发布的安全公告有关的其他安全信息。不幸的是,如果没有正确检测到扫描组件的源产品数据,安全扫描程序可能会使用不正确的输入数据,然后无意中做出错误的评估,并得出误报。

    例如,如果您对 OpenShift 4.10.17 进行了安全扫描,并且在报告中有重要的 RHSA(如 RHSA-2021:4647)未被应用的信息。在这种情况下,您应该:

    • 检查报告的 RHSA ,并验证安全公告中包含的 CVE。RHSA-2021:4647 与内核软件包漏洞 "CVE-2021-20317", "CVE-2021-43267" 有关
    • 检查正在被扫描的产品的软件包版本和数据源(您可以根据软件包扩展名来进行检查)。
    • 检查扫描程序在建议的 SHSA (本例中为 "CVE-2021-20317", "CVE-2021-43267")中报告的 CVE 的红帽 CVE 页上特定软件包和产品数据源的相应的修复。
    • 检查一个 CVE,例如 CVE-2021-20317,并比较 OCP 4.10.17 中当前安装的内核软件包的信息,即 4.18.0-305.49.1.el8_4,您会发现,对于 Red Hat Enterprise Linux 8.4 延长更新支持,固定内核版本是在 RHSA-2021:4650 中提供的,而不是在 RHSA-2021:4647 中提供的,因为其在扫描报告中已报告了。通过将 RHSA-2021:4650 中的内核软件包版本与安装的版本进行比较,您可以确认安装的版本已被修复。

尽可能补救和缓解

补救和缓解是安全工程师在审查漏洞扫描时要考虑的两个目标。补救非常简单,通常要确保有一个准备好的计划来使用任何供应商提供的包含修复的新版本来更新受影响的组件。如果确认的漏洞没有可用的较新的修复版本,有时可以通过应用缓解步骤来降低风险。

缓解的第一步是区分常规的操作系统(裸机或虚拟环境)和容器化环境。对于常规的操作系统环境,可以使用 Red Hat CVE 页面上提供的缓解步骤。
例如,请参阅 CVE-2021-4034 中的缓解部分。

容器化环境中的漏洞缓解可能更加困难。为了说明我们的计算机系统的复杂性,请考虑在一个典型的 OpenShift 系统中,通常每个 Linux 软件包至少存在于四个位置 — 底层主机系统上,即 control控制平面中的容器镜像内,平台工作节点的容器镜像内,以及用户提供的工作负载的容器镜像内。

根据第 1 步中的知识,"删除重复和误报",可以验证是否可以应用缓解措施或补救流程。例如,CVE-2022-2403 显示了一个缓解流程示例,可通过在集群中部署自定义的 webhook 来将其应用到 OpenShift 产品中。请阅读 容器漏洞风险评估 以更好地了解。此博客文章包括了在"缓解受影响的软件包"部分的自定义的、用户提供的工作负载中缓解与 rpm 软件包相关的漏洞的示例。

与供应商一起确定任何未解决漏洞的优先级

有两种常见的场景来描述未解决的漏洞。那些标记为"will not fix"以及标记为未解析的漏洞。标记为 will not fix 的问题将被视为已解决,虽然处于待处理状态的问题并没有被解决。

  • 如何处理"Will not fix"

    当特定漏洞的红帽风险评估(红帽严重性评级)为低或中等严重时,并且产品团队决定不处理特定的问题而优先处理其他优先事项时,就设置"Will not fix"状态。这与产品生命周期及支持模式直接相关。如果解决标记为"Will not fix"的漏洞对你很重要,请开一个 支持问题单,通过说明为什么其如此重要,来请求优先发布此漏洞的修复。

  • 如何处理未解决的漏洞

    在分析漏洞时,红帽产品安全团队会通知所有受影响的产品。当特定漏洞的风险评估(红帽严重性评级)为低或中等严重,且产品团队尚未决定何时解决该漏洞的决定时,就会出现未解决的漏洞。低和中等 CVE 通常在主产品版本中解决,而不是异步勘误表中。与"will not fix"类似,如果处理一个未解决的漏洞对于您来说非常重要,请开一个 支持问题单,通过说明为什么其如此重要,来请求优先发布此漏洞的修复。

收集必要的红帽安全数据

不一致和不准确的安全数据、扫描目标版本匹配和各种漏洞检测方法是漏洞扫描困难的主要原因。检测所有不正确的结果是另一个巨大的挑战。要正确分析并验证安全扫描报告,需要多次从不同的地方收集必要的数据
红帽数据源(如安全数据 API、红帽公告、容器元数据)。

cve-analyser 工具是一个公共项目的示例,它整合了针对特定 CVE 的所有的红帽安全数据,这有助于在漏洞风险评估过程中的下一步中做出正确的决定。

cve-analyser 工具评估红帽容器镜像详情(容器元数据)。它使用容器镜像详情来检测和提取所报告漏洞的所有必要的安全信息。如果红帽安全数据中有必要的信息,则 cve-analyser 工具会评估与容器 RPM 软件包和非 RPM 内容相关的漏洞数据。它还可以在软件包/工件名称和扫描程序 CVE 报告的名称之间进行简单的关联,而不是进行深度容器镜像相关性验证(模糊搜索)。

cve-analyser 工具要求输入文件(.CSV 格式)中有两个参数:

  • 由第三方安全扫描程序检测到的 CVE id(作为第一个参数)
  • 报告为 潜在 影响的容器名称(第二个参数)

用户也可以将报告的漏洞的软件包/工件名称指定为第二个参数,而不是容器镜像名称。
然后 cve-analyzer 工具做一个简单的模糊搜索,并显示 CVE 安全数据中所有可能提供的信息。

cve-analyser 工具需要以下格式的容器名称:
repository_name/container:tag
此容器镜像命名规则与 红帽容器门户网站 上的一样。
例如,OpenShift Grafana 容器应当列在输入文件中,如
openshift4/ose-grafana:v4.10.0-202205311508.p0.g48aec35.assembly.stream.
要正确检测所有容器元数据,必须使用容器名称的确切格式。

作为输出,用户将获得有关以下内容的所发现的漏洞信息的列表:

  • 修复状态(如果特定目标不受影响)
  • 产品级影响(因为每个产品可能受到同一漏洞的不同影响)
  • 可用的修复(不同的产品流可能有很多修复)

如果工具无法检测容器镜像(或软件包)和红帽安全数据中报告的 CVE 间的任何相关性,则它将显示消息 "Not Found Any Information"。此类情况需要手动验证,因为盲目假定一个误报并不是好的做法。

cve-analyser 工具的输出示例:
https://github.com/p-rog/cve-analyser/blob/main/samples/mix-output.csv

请联系红帽产品安全团队

本教程中的推荐的流程可以指导安全团队管理漏洞扫描数据,但我们知道仍然会有问题。 有关数据差异的问题或对潜在数据缺口的担忧,请向 secalert@redhat.com 发送电子邮件来联系红帽产品安全团队

以下是联系红帽产品安全团队的一些场景示例:

  • CVE 的红帽严重性评级似乎并不正确,您发现了一个漏洞补丁,这应该会对 CVE 的严重性评级产生重大影响。
  • CVE 不会记录在红帽 CVE 数据库中,根据执行的漏洞分析,有证据证明红帽产品受到了特定的 CVE 的影响。

当联系红帽产品安全团队时,请提供以下信息:

  • CVE ID
  • 关于扫描的产品和组件的详情
    (如:OpenShift 4.10.2 / grafana-container 或 OpenShift 容器 openshift4/ose-grafana:v4.11.0-202208291725.p0.g6773185.assembly.stream)
  • 漏洞是如何被检测出来的(scanner 工具名称和版本)
  • 漏洞证据:检测到的漏洞的路径和工件

Comments