tags: 漏洞分析

漏洞分析与复现模板

在开源软件安全研究方法一文中，我们提到, 漏洞复现工作需要有规范的、成体系的进行。

  1. 有规范的、成体系的分析、复现并存留实验环境，可以利用vagrant或docker记录、分享漏洞环境。
  2. 不只是复现漏洞，更重要的是复现漏洞挖掘的方法或过程（能应用于同类漏洞挖掘）

本文将具体提出一个漏洞分析与复现过程中，要做的事情的模板。与前文同样，本文仅列举需要做哪些工作，并未指出具体应怎么做。在我历史及未来关于历史漏洞分析与复现的文章中，可以看到关于本文实际应用的实例。

一、基本信息

Item Details Note
Project link
Publish Date 1970-01-01
Introduce Date 1970-01-01
Confirm Link link
CVE-ID CVE-0000-0000 mitre, cvedetails
EDB-ID EDB-00000
Exploits exp1
exp2
Affect Version 0.0.0-9.9.9
Fix Version 0.0.0, 1.1.1
Fix Commit commit
Introduce Commit commit
CVSS 0.0 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Vuln’s Author http://github.com/xxx

二、组件简介

把组件、组件涉及的功能简单介绍下

三、漏洞作者

四、漏洞详情

1. 介绍

1.1 原始特性

1.2 漏洞介绍

2. 影响

2.1 范围

2.2 危害

2.3 利用场景

五、防御

1. 修复建议

2. 规避措施

3. 检测

六、漏洞复现

1. 复现环境

2. 漏洞复现

七、漏洞分析

1. 原始特性分析

2. 调用链分析

3. 漏洞分析

八、漏洞修复分析

1. 修复分析

2. 修复效果验证

3. 当前修复局限性

4. 该修复有无引入新漏洞

因漏洞修复的作者水平参差不齐：

  1. 作者可能不是核心开发者
  2. 作者非安全背景

漏洞修复引入新漏洞的案例屡见不鲜，应引入这一环节

九、漏洞挖掘方法与过程

1. 原作者的漏洞挖掘方法

  • 如果可以推测原作者的漏洞挖掘方法的话，可以记录; 如果没有可以忽略

2. 有无可能早于作者或业界发现

例如，漏洞修复的commit早于漏洞公告等情况

十、同类问题挖掘方法

level 挖掘方法
设计层
安全模型
Fuzz
codeql

十一、总结

十二、遗留事项

附

时间线

漏洞产生、发现、报告、修复的时间线

e.g.: cve-2019-14271的时间线