用 Trivy 扫描新操作系统的漏洞

Trivy 是个来自 Aqua Security的漏洞扫描系统,现已经被 Github Action、Harbor 等主流工具集成,能够非常方便的对镜像进行漏洞扫描,其扫描范围除了操作系统及其包管理系统安装的软件包之外,最近还加入了对 Ruby、PHP 等的漏洞检测,应该是该领域目前目前采用最广的开源工具之一了。

在我们使用 Trivy 对系统进行扫描加固的时候,遇到了一个问题,openEuler 这样的年轻操作系统,还没被 Trivy 接入其数据库之中,如何能借助这样的主流工具进行漏洞扫描呢?

漏洞的发现、处理、披露是个复杂的流程,下面引文来自我的译作《容器安全》(《Container Security: Fundamental Technology Concepts that Protect Containerized Applications 1st Edition》(Liz Rice)):

一旦发现了新的漏洞,赛跑就开始了,系统管理员必须抢先修复漏洞,否则就可能遭受针对性的攻击。如果直接公开发布新问题,就相当于为攻击者开启了利用漏洞的自由竞赛。为了避免这种情况发明了一个概念,叫做负责任的安全披露。发现漏洞的安全研究人员会联系相关软件的开发者或供应商。双方商定一个时限,在这个时限之后,研究人员可以公布他们的发现。在这里,对供应商来说,有一些积极的压力,要求他们努力及时提供修复,因为在公布之前提供修复,对供应商和用户都有好处。 新发现的问题会有一个唯一标示符,前缀为 CVE,是 Common Vulnerabilities and Exposures 的缩写,CVE 后面是年份代码。例如 ShellShock 漏洞是 2014 年被发现的,其标示符为 CVE-2014-6271。管理这些编码的机构是 MITRE,MITRE 监管着一些 CVE 编码授权机构(简称 CNA),CNA 能够在特定领域中签发 CVE ID。有些大型软件商(例如微软、红帽以及 Oracle)就是 CNA, 能在各自产品范围内授予 CVE 编码。Github 在 2019 年末也获得了 CNA 资格。 在 NVD(National Vulnerability Database(国家漏洞数据库)) 中使用 CVE 编码跟踪受到该漏洞影响的软件包和版本。有了受影响的软件包版本的列表,所以如果当前使用的软件版本出现在这个列表里,是不是代表当前环境已经受到影响了?并不一定,这和当前使用的 Linux 发行版是相关的,可能发行版自身已经针对该软件包发布了一个补丁版本。 以 ShellShock 为例。这是一个存在于 GNU Bash 中的严重漏洞。NVD 上的 CVE-2014-6271 页面里列出了一个很长的列表,覆盖了从 1.14.0 到 4.3 的版本范围。如果运行一个旧版本的 Ubuntu 12.04 并且发现其中的 Bash 版本是 4.2-2ubuntu2.2,你可能会认为这是一个基于 bash 4.2 的版本,属于受影响之列。 实际上根据 Ubuntu 的官方说法,这个版本已经修复了该漏洞,是安全的。Ubuntu 维护者认为,与其让所有 12.04 用户升级到全新的 bash 版本,不如单独进行补丁并发布一个小的补丁版本。

因此扫描工具除了需要关注 CVE 的通用信息之外,更重要的是引入发行版开发商的安全数据库,才能准确地完成扫描任务。

Trivy 的基本功能

Trivy 工具链

Trivy 自身只是一个扫描工具,实际上支撑这个工具的还有一个工具链,多种工具/库的协同,完成了从 CVE 到扫描识别的各个环节,其中包括:

  • vuln-list-update:负责更新各个来源的威胁数据,转换成 JSON 数据,保存在 vuln-list 项目之中。
  • trivy-db:既是工具,也是库,用于操作 Trivy 的数据库。
  • fanal:从 vuln-list 获取数据,并构建成 bbolt 格式的数据库文件,可以用 upload 命令上传到 Github Release。
  • Trivy:获取 trivy-db 的 Release 数据,进行漏洞扫描工作。

综上所述,Trivy 的总体工作流程:

  1. 从操作系统厂商等 CVE 源获取数据,使用 vuln-list-update 脚本进行汇总,转换为一致的 JSON 数据,保存到 vuln-list 项目。
  2. trivy-dbvuln-list 下载数据,转换为 bbolt 格式,发布到 trivy-db 的 Release。
  3. Trivy 下载 trivy-db 数据,作为本地检测的数据源。

Trivy 的扫描流程

Trivy 首先会使用 Fanal 对待扫描镜像进行检测,Fanal 会根据基础镜像哈希码查询缓存(MACOS 中是 ~/Library/Caches/trivy/fanal/fanal.db)中是否保存了对应的“哈希-操作系统”记录,如果没有,则会解压基础镜像层,遍历其中文件,并根据其 analyzer 中包含的各个操作系统的文件特征来判断基础镜像的操作系统,例如 Alpine 的特征文件是 etc/alpine-release,而 Photon 的特征文件是 usr/lib/os-releaseetc/os-release;如果有,则直接从缓存数据中取出对应的操作系统名称和版本。

ospkg 中的 detect.go 中硬编码了操作系统和扫描器的对应关系,例如:

case fos.RedHat, fos.CentOS:
  return redhat.NewScanner()

确定了具体的扫描器之后,就会调用具体的扫描器,根据漏洞库 ~/Library/Caches/trivy/db/trivy.db 作为数据源进行扫描。

扫描新操作的方法

篡改 Fanal 缓存

如果我们假设新系统可以和 Redhat 8 共享同样的漏洞库,就可以直接在 Fanal 缓存中加入 新的的镜像关系,对应到 Redhat 8 上,就能够进行扫描了,例如:

fake

正式一点的方式

篡改缓存的扫描方法是非常不负责的,这大概不会代表真实的操作系统安全现状。根据上文工具链的介绍,应该能清楚地了解到这个过程:

首先要 Fork vuln-list-update,其中加入新操作系统的数据源,并转换为通用格式,例如:

{
    ...
 "cwe": "CWE-120",
  "statement": "",
  "acknowledgement": "",
  "name": "CVE-2021-0326",
  "document_distribution": "",
  "details": [
    "In p2p_copy_client_info of p2p.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution if the target device is performing a Wi-Fi Direct search, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-8.1 Android-9Android ID: A-172937525"
  ],
  "references": [
    "https://w1.fi/security/2020-2/wpa_supplicant-p2p-group-info-processing-vulnerability.txt"
  ]
  ...
}

接下来要修改 Fanal,除了在其中加入新系统的甄别方法,例如 /etc/openEuler-release 的解析过程。

然后是创建新操作系统的扫描器,基本上可以参照 Debian/Redhat/Alpine 几个大体系的扫描器完成工作。

上述工作可以通过分叉的方式自己独立运行,也可以通过 PR 的方式回馈给 Trivy 项目组,公开成为通用的扫描方案。

Avatar
崔秀龙

简单,是大师的责任;我们凡夫俗子,能做到清楚就很不容易了。

comments powered by Disqus
下一页
上一页