JFrog高级安全上下文分析功能确定DockerHub映像上78%的cve是不可利用的

研究动机

类似于我们之前对"秘密检测，“在JFrog Xray新产品的开发和测试期间”语境分析”特性，我们想要在一个大规模的真实用例中测试我们的检测，既为了消除bug，也为了测试我们当前解决方案的真实可行性。

然而，与我们在秘密检测研究中得到的令人惊讶的结果(比我们所期望的要活跃得多的令牌)不同，在这种情况下，结果与我们作为安全工程师多年来所看到的一致。即,当一个易受攻击系统的度量仅仅是“安装了包X”时，我们预计绝大多数安全警报都是误报。

在这篇文章中，我们将详细介绍我们的研究方法和发现，并为希望减少CVE误报数量的开发人员和安全专业人员提供一些建议。

实际可利用vs.“安装了易受攻击的软件包”

在深入研究之前，让我们简要查看一些示例漏洞，以了解CVE报告可能被视为误报的情况，即使存在易受攻击的组件。

无论如何，这不是一个详尽的清单，但它确实涵盖了CVE假阳性的最突出的煽动者-

图书馆的漏洞

是否安装了易受攻击的Lodash版本就保证了一个易受攻击的系统?

不!根据定义，我们不能仅仅通过注意库的安装来确定库中的CVE是否可被利用。这是因为库不是一个可运行的实体;一定有系统中的其他代码以易受攻击的方式使用库。

在上面的示例中，即使安装了Lodash，系统也可能不会受到攻击。肯定有一些代码调用了易受攻击的函数，在这种情况下，模板()来自脆弱的洛达什图书馆。在大多数情况下，甚至还有额外的要求，例如传递给的参数之一模板()是由攻击者控制的。

其他与代码相关的先决条件可能包括-

是否在脆弱函数之前调用缓和函数
是否将脆弱函数的特定参数设置为特定的脆弱值

服务配置

安装了易受攻击的卡桑德拉版本，就能保证系统易受攻击吗?

不!在大多数现代服务漏洞(特别是具有严重影响的漏洞)中，漏洞仅体现在服务的非默认配置中。这是因为默认和相同的配置通常测试最多，要么是由开发人员自己测试，要么只是由服务的实际用户测试。

在上面的示例中，要实现RCE，必须配置Cassandra服务三个非默认配置标志(其中一个非常罕见)。

其他与配置相关的先决条件可能包括-

组件是否使用特定的命令行参数或环境变量运行
是否使用特定的构建标志编译易受攻击的组件

运行环境

安装了一个易受攻击的Apache Hadoop版本，就保证了系统易受攻击吗?

不!在上面的示例中，该漏洞仅显示在基于微软Windows的环境中。因此，如果将易受攻击的组件安装在Linux环境中，则无法利用它。

其他与环境相关的先决条件可能包括-

易受攻击的组件是否在特定的发行版中运行(例如Debian)
是否针对特定架构编译易受攻击的组件?(例如32位ARM)
防火墙是否阻断易受攻击服务的通信

我们的研究方法

在这项研究中，我们打算在考虑两种报告技术时，找出漏洞报告实际上表明漏洞可被利用的百分比

幼稚-只要在相关(易受攻击的)版本范围内安装了易受攻击的组件，就会报告该漏洞。这是当今几乎所有SCA工具的工作方式。
上下文敏感-仅报告漏洞(或-)据说是适用的)如果……上下文图像的值表示该组件被脆弱地使用。这将考虑到前一节中讨论的因素(代码先决条件、配置先决条件、运行环境)。

我们感兴趣的是在常见的真实环境中测试上述内容，并在尽可能多的环境中执行此测试。

我们意识到这一点DockerHub的顶级“社区”图像应该满足这两个要求，因为-

使用这些图像非常频繁的。例如，排名前25位的图片目前有超过10亿次下载。
社区图像通常包含这两者一个有趣的组件和使用该组件的代码，它提供了一个现实的背景。这与通常包含的“官方”docker映像不同独立的组件它们被保留在其默认配置中未使用。例如，默认配置的Nginx web服务器本身可能不会受到任何主要CVE的影响，但它并没有提供一个现实的场景。

从这些决定中，我们的方法出现了

拉DockerHub的前200个社区图片，在他们的“最新”标签
从这些图像中收集10个最“流行”的CVE(按CVE在所有图像中的出现次数排序)
对这200张图片进行背景分析
通过将前10个cve的“不适用事件”除以“总事件”，计算朴素法假阳性率的百分比

十大最受欢迎的cve是什么?

当扫描DockerHub的前200个社区图像时，这些是出现在图像中最多的cve -

CVE ID	CVSS	简短的描述
cve - 2022 - 37434	9.8	Zlib到1.2.12在膨胀()中有一个基于堆的缓冲区过读或缓冲区溢出。只有调用inflateGetHeader的应用程序会受到影响。
cve - 2022 - 29458	7.1	Ncurses 6.3在convert_strings()中有越界读取和分段冲突
cve - 2021 - 39537	8.8	nc_captoinfo()具有基于堆的缓冲区溢出
cve - 2022 - 30636	N/A	Golang x/crypto/acme/autocert: httpTokenCacheKey允许在Windows上有限的目录遍历
cve - 2022 - 27664	7.5	在1.18.6之前，由于HTTP/2连接可能挂起，所以Golang net/http会DoS
cve - 2022 - 32189	7.5	Golang数学/大之前1.17.13浮动。GobDecode和Rat。由于恐慌而解码DoS
cve - 2022 - 28131	7.5	Golang encoding/xml之前的1.17.12 Decoder。由于堆栈耗尽，跳过DoS
cve - 2022 - 30630	7.5	1.17.12之前的Golang io/fs由于不受控制的递归导致Glob DoS
cve - 2022 - 30631	7.5	1.17.12 Reader之前的Golang compress/gzip。由于不受控制的递归而读取DoS
cve - 2022 - 30632	7.5	1.17.12之前的Golang path/filepath由于堆栈耗尽而导致Glob DoS

那么，究竟有多少cve是可利用的呢?

我们故意选择在最保守的设置上运行上下文扫描器——下一节将详细介绍。

每个CVE的上下文扫描器定义如下-

CVE ID	上下文扫描仪
cve - 2022 - 37434	检查1 st-party代码调用" inflateGetHeader "和" inflateGetHeader "
cve - 2022 - 29458	检查对护士“tic”CLI实用程序的调用
cve - 2021 - 39537	检查对护士“captoinfo”CLI实用程序的调用
cve - 2022 - 30636	检查Windows OS +第一方调用“autocert”的代码。新监听器“或引用”autocert。DirCache”
cve - 2022 - 27664	检查调用“ListenAndServeTLS”的第一方代码(HTTP/2仅在TLS上可用)
cve - 2022 - 32189	检查第一方代码是否调用“老鼠”。“GobDecode”或“Float”。GobDecode”
cve - 2022 - 28131	检查调用“解码器”的第一方代码。跳过”
cve - 2022 - 30630	检查调用“fs”的第一方代码。具有非恒定输入的Glob”
cve - 2022 - 30631	检查调用“gzip.Reader.Read”的第一方代码
cve - 2022 - 30632	检查调用“filepath”的第一方代码。具有非恒定输入的Glob”

在所有200张图像上运行上下文扫描仪给了我们以下结果，每个CVE -

当把前10名cve的结果加在一起时，78%的CVE病例不适用!

区分第一方和第三方代码

上下文分析器使用Xray的SCA功能，以文件级粒度区分第一方和第三方代码。

我们将第一方代码定义为供应商自己的代码，这意味着由运行上下文分析器的供应商直接编写的代码(与供应商使用的第三方OSS代码相反)。

当我们进行上下文分析时在代码(与配置或环境上下文分析相反)我们只关心如何第一方代码与第三方组件交互。

例如，对于下面的CVElodash(一个npm库)，我们可以看到文件" /project-two/main.js "正在调用易受攻击的API -

这是一个不属于任何OSS组件的第一方文件，因此它被包含在上下文扫描中。与此相反，如果同一个Docker容器也包含react-colorNPM包(依赖于lodash)，然后是类似的文件Compact.js不会被扫描，因为它是反应颜色第三方组件的一部分(即使文件使用lodashAPI调用)-

为什么我们不扫描第三方组件对第三方组件的使用情况?有几个原因

范围-当一个流行的库或应用程序容易受到特定问题/CVE的攻击时，这取决于库/应用程序的维护者修复该问题并发布新版本的库。例如，此信息存储在cpCVE的列表。例如，直接影响Log4j Java库的Log4Shell漏洞(CVE-2021-44228)的cpe也包含以下思科WebEx的条目:
对于上下文分析器来说，分析cve -2021-44228相关API调用与Cisco Webex相关的(第三方)文件是多余的，因为我们已经通过这些cpe了解了Cisco Webex的易受攻击版本。
性能——在几乎所有现代软件项目中，第三方代码的数量通常小矮人第一方代码的数量(想象一下链接到整个C库的一行程序)。扫描所有第三方代码将是极其冗余的，并且不允许我们实现期望的工件扫描时间
许可——在使用专有第三方组件(例如二进制格式)的情况下，第一方供应商可能没有批准来分析专有第三方组件。

看看上下文分析目前的局限性

让我们来看看CVE-2022-30631，它的应用率非常高。

CVE是唯一一个超过50%适用性的。通俗地说，这个CVE被利用的先决条件是“Golang用于提取一个attacker-controlled如果第一方Golang代码试图提取任何gzip存档，扫描器将发出警报。这样做是因为保证了a文件由于影响文件的可能源众多，因此攻击者控制文件是一项非常困难的任务。当试图确定是否变量来自恒定输入或外部/攻击者输入，这可以通过例如数据流分析来实现(这是由我们的一些扫描仪执行的，例如CVE-2022-30630，其适用性要低得多)

但是，在处理文件时，即使函数的文件路径参数是常量，也不能保证文件不受攻击者控制，反之亦然。因此，我们预计该CVE的实际适用性甚至更低。

为什么78%实际上是一个保守的数字

从上面的例子中，我们可以看到一些cve可能有一个夸大的适用性率，这意味着现实世界的适用性可能更低。讨论为什么(在通常情况下)运行保守扫描器仍然是有意义的是很重要的

偏爱假阳性而不是假阴性

实际上，任何技术都有其局限性，当试图解决计算上不可行的问题时，例如“某个输入是否可以由外部源控制”，这种局限性就更加明显了。在某些情况下，更简单的情况下，我们可以做出某些假设，使解的计算具有极高的可信度。然而，我们推测，在更困难的情况下，100%的信心不能保证，我们应该做两件事-

更喜欢倾向于显示假阳性的扫描器(在我们的例子中，显示的结果是适用的，而实际上它们不是)。这样做是因为在这种情况下，结果将由工程师检查并评估它是否真的适用。在相反的情况下，当漏洞被标记为“不适用”时，工程师会认为它可以被忽略，从而使它变得脆弱，这是一个更严重的场景。
只要有可能，提供对特定发现的置信度和/或低置信度的原因，这样即使是适用的结果也可以由安全/DevOps工程师优先考虑。

性能考虑

基于数据流分析的上下文扫描器(例如，试图确定特定函数的参数是否来自攻击者控制的输入的扫描器)在其实现中总是有一个选项，是提供更准确的结果还是运行得更快。例如，最精确的上下文扫描器类型必须最后-

当尝试在攻击者控制的源和请求的接收器之间构建模块内数据流图时，允许无限调用深度
在构建数据流图时考虑模块间调用

这些操作大大增加了扫描仪的运行时间。

当每分钟处理大量扫描工件时(可能要求JFrog Artifactory/Xray实例)，必须在上下文扫描仪的准确性和速度之间取得微妙的平衡。

即使考虑到所讨论的限制，78%仍然是一个巨大的可以取消优先级或忽略的漏洞数量，我们预计随着技术的进步和越来越少的“默认适用”cve被发现，这个数字会越来越高。

在2022年——忽视背景是没有意义的

随着时间的推移，我们看到可以在没有任何先决条件的情况下利用的漏洞越来越少。库漏洞总是有一个代码先决条件(必须有人以易受攻击的方式使用库)，并且在默认配置中Daemon漏洞不太可能被利用，因为该配置通常是高度审计的。

正如我们从研究结果中看到的那样，即使在常见的用例中以及使用保守的、高精度的分析技术时，不适用cve的数量也是惊人的。

我们相信这些事实已经为许多安全工程专业人员所熟知一段时间了，因为他们每天都在“战壕中”，试图将小麦从谷壳中分离出来。现在是时候从完全手动的方法转向将更好的DevSecOps方法集成到漏洞修复过程中了。

研究是语境分析的核心

不幸的是，今天它仍然是无法自动定义执行精确上下文分析所需的规则。几乎所有的漏洞通知都不包含格式化的字段(甚至是自由文本)，这些字段提供了为每个CVE执行上下文分析所需的信息。例如，受影响组件的脆弱功能或脆弱配置是什么。

虽然通用技术是可能的(例如，检查是否导入了易受攻击的库，或者检查是否通过运行时钩子启动了易受攻击的服务)，但它们永远不会提供所需的准确性，只有使用每个cve上下文扫描器才有可能。

在这个领域备受欢迎的先驱之一是Go漏洞数据库每个安全咨询还包含易受攻击的函数列表。虽然这并不能解决100%的问题，但这是一个了不起的开始，我们为他们将这些数据编目而鼓掌。

JFrog的上下文分析基于JFrog安全研究团队的日常工作，在每个新漏洞被披露的当天进行分析，以提供最快、最准确的上下文分析。

上下文分析与JFrog高级安全

这项研究是由新的“上下文分析”功能提供支持的，该功能包含在最近的JFrog高级安全宣布JFrog Xray的一组功能。这个版本将JFrog Xray从它熟悉的软件组合分析领域带到了先进的软件供应链安全y。

上下文分析使用工件的上下文来确定漏洞是否适用。此过程涉及在容器映像上运行自动上下文扫描程序，以确定可达路径和分析漏洞的配置设置。Xray自动验证高影响和非常高影响的漏洞，例如那些具有利用先决条件的漏洞，并提供上下文分析信息，以帮助确定哪些是适用的，哪些是不适用的。这为开发人员节省了大量的时间和精力。

通过只修复适用的漏洞来节省开发人员的时间
像攻击者那样分析完成的代码(二进制)
了解哪些cve是可利用的，以及它们的潜在影响
在完整工件、构建或发布包的上下文中测试漏洞
在工件、构建或发布包的上下文中启用操作和修正

事实证明，在顶级DockerHub映像上报告的cve中，有78%并不是真正可利用的