---
# System prepended metadata

title: '[Towards Reliable and Scalable Linux Kernel CVE Attribution in Automated Static Firmware Analyses](https://arxiv.org/abs/2209.05217)'
tags: [paper]

---

# [Towards Reliable and Scalable Linux Kernel CVE Attribution in Automated Static Firmware Analyses](https://arxiv.org/abs/2209.05217)

## Abstract

* 基於元件的 CVE 去評估系統漏洞是常見的方法，但在 Linux kernel 中會有高誤報率
* 利用靜態分析 firmware 去強化 CVE 的匹配

## Introduction

* 至 2022 年，超過 2900 個常見漏洞和 CVE 影響不同的 Linux kernel 版本
    * 各種韌體依然使用這些過時的 kernel
* 目標：找到裝置漏洞且了解原因(主要是已知漏洞)
* 動態分析會遇到的問題
    * 架構很多種，不同架構之下可能導致漏洞無法觸發、利用
    * 需要真實設備執行，模擬則是要建立環境
* 靜態分析的問題
    * 手動分析耗時，且需要對 CVE 要有一定了解
    * 自動化的可能不正確，且面對混淆、編譯優化、符號剝離會遇到問題
* 因此許多分析工具都直接將版本對應到 CVE 數據庫來歸因錯誤
    * 但很多 kernel 其實會經過修改，導致誤報發生
* 利用自動靜態分析 firmware，提取 kernel 配置，辨識包含的元件，減少假陽性發生率
* [Open Source](https://github.com/fkie-cad/cve-attribution-s2)

## Background and Related Work

* 除了基於版本去匹配 CVE 之外，常見的方法還有
    * code 相似度分析
    * 汙點分析
    * 符號執行
* linuxkernelcves.org 認為 Linux 有太多版本、貢獻者，CPE 數據沒辦法準確的追蹤出受影響的版本
* 錯誤歸因的研究最早在 2014 年就有了，當時 CVE 數據不完整且受自行補丁影響
* FirmSec 辨識元件漏洞，但不考慮 Linux kernel

## Methodology

* ![](https://i.imgur.com/EkhZymB.png)
* 兩個階段
    * 第一階段解包韌體並分析，收集 kernel 版本、ISA、kernel 配置等
    * 第二階段根據數據執行 CVE 歸因和過濾
* 圖中黃色的部分是本文貢獻的元件

### Gather Kernel Information via Static Firmware Analysis

* 收集 kernel 資訊是利用韌體分析工具 FACT
    * 該工具也是他們團隊維護的
    * FACT 開源、用於對韌體解包並分析
* 第一階段
    * 以 binwalk 解包後，將每個提取的文件用預先配置的分析插件分析(基於 YARA、第三方工具)
    * 使用軟體元件、kernel 配置和架構檢測三個結果
    * 本文主要提供新的 kernel 配置插件
* 第二階段
    * ![](https://i.imgur.com/TRj2vUa.png)
    * kernel 配置可能是純文本或是 binary 檔案
        * 先檢查是否有純文本
        * 不是的話就檢查 magic number 去檢測正確的格式
    * 根據上面的資訊，解析出 kernel 的架構

### Build Log-assisted CVE Attribution

* 建立 CVE 歸因 log 是第二階段的第一個步驟
* 藉由前面 FACT 分析的資訊得到 kernel 版本、kernel 配置和 ISA，從 kernel.org 下載對應的版本
    * 自訂補丁和專有元件目前不考慮
* 接著藉由 build 的 make 指令去收集哪些 source file 在 kernel 中
* 同時查詢 Linux kernel CVE 數據庫
* 最後過濾 kernel 版本的 CVE 中不存在的元件，輸出最後的 CVE

### Short Example - CVE-2017-17863

* CVE-2017-17863 是在 kernel/bpf/verifier.c 中存在 BOF 漏洞
* CPE 表示 4.9 ~ 4.9.71 的 kernel 版本都有此問題
* 但如果編譯時將 BPF 關閉，最後的報告就會將該 CVE 排除
    * 因為編譯文件中會排除該文件

## Case Study

* Home Router Security Report 2020 這份報告中，廠商表示基於版本的 CVE 有高誤報率
* 提出兩個研究問題
    * 該方法需要訪問 firmware 和 CVE 資料庫，現實世界的適用性如何
    * 和一般基於版本的 CVE 匹配比較，該方法的可靠度

### Experiment and Firmware Corpus

* AMD Ryzen 7 2700x processor and 32 GiB DDR4 RAM
* Ubuntu 20.04.4 LTS
* FACT v4.0 (commit 38df4883)
* 使用 Home Router Security Report 2020 中所有的 firmware
    * ![](https://i.imgur.com/CdD2u9n.png)
    * ![](https://i.imgur.com/m8spxEz.png)
    * 大部分都是路由器

### R1 Analysis – Applicability in Real-World Scenarios

* ![](https://i.imgur.com/pxGDJgp.png)
    * 第一階段中，127 個 firmwares 成功提取 116 個
    * 成功辨識 103 個架構和版本
    * 但 kernel 配置卻只成功辨識 44 個
* 失敗原因
    * IKCONFIG 必須啟用才能將 kernel 配置匯出
    * firmware 可能被剝離或混淆
    * 有些 CVE 根本不存在文件參考，此時只能退回基於版本的匹配

### R2 Analysis – Impact on CVE Attribution Result Reliability

* ![](https://i.imgur.com/FTBKDhz.png)
* 在上述 44 個成功分析的韌體中，Linux kernel 相關的 CVE 存在 68.37 % 為誤報
    * 在 build log 中根本不存在受影響的文件

## Limitations

* 如果 kernel 版本、ISA 或 kernel 配置無法分析就無法使用
* 如果供應商修改了 kernel，該方法可能不會發現

## Conclusion

* 針對 Linux kernel，基於版本的 CVE 匹配有高誤報率
* 利用靜態分析 kernel 的建構過程，猜測包含的 source file 來降低誤報率

###### tags: `paper`