转载地址：https://blog.csdn.net/think_ycx/article/details/83061114
浅谈固件漏洞扫描技术框架—fiber
本篇主要介绍使用fiber框架来扫（fan）描（yi）固（read）件（me）漏洞的过程。这个框架似乎可能是UCR的seclab实验室的一个开源项目，但是却在angr的仓库中（从angr fork而来的）。我们参考UCR仓库中的fiber来介绍它的工作原理。
设想如下的一个场景：我们有了target kernel，如Android的boot.img或者是linux kernel的/boot/分区下的kernel。如何知道自动化的知道历史的CVE有没有被patch呢？最简单的方法是：用poc跑一跑，看看crash或者dmesg信息。没有poc的情况，手工反汇编，人肉分析kernel的img。那么，当部分漏洞没有公开poc时，如何自动化的分析target kernel的历史cve patch情况呢？fiber就是为了解决这个问题的。
项目repo：https://github.com/seclab-ucr/fiber
首先设想一下没有fiber时，我们应该如何人工判断kernel中的二进制文件有没有被patch？通常，kernel的漏洞被patch时，通过diff源码的信息，我们可以发现对应的更新的代码。再查看kernel的反汇编/编译代码时，我们可以定位到对应的函数查看是否被patch。这部分工作，fiber是如何自动化实现的呢？
接下来，粗略的讨论一下fiber的工作流程。大概可以分为4步：
提取cve patch信息的特征：收集需要判断是否patch的cve列表的 diff信息，使用picker（pick_sig.py）来生成对应的cve change列表信息(ext_list)。该列表中记录了每个cve patch信息中比较适合的一些特征，修改的最多的一些函数等信息（一个cve可能对应多个change信息，可能有多个函数可以作为特征）。
CVE-2016-10230 qce_aead_req 4491-4492 match_reg_set:x0,x1 trim_non_tail_roots:True
CVE-2016-10230 qce_aead_req 4491-4492,4499 match_reg_set:x0,x1 trim_non_tail_roots:True
CVE-2016-10230 qce_aead_req 4491-4493 match_reg_set:x0,x1 trim_non_tail_roots-4491-4492:True
CVE-2016-10232 mdss_fb_force_panel_dead 602 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouint
CVE-2016-10232 mdss_fb_change_dfps_mode 716 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouint
CVE-2016-10232 mdss_debug_factor_write 688 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouint
CVE-2016-10234 ipa_generate_flt_hw_tbl_v2 777-778 match_reg_set:x0,x1,x2,x3 trim_non_tail_roots-778-778:True
CVE-2016-10234 ipa_generate_flt_hw_tbl_v2 778 match_reg_set:x0,x1,x2,x3 trim_non_tail_roots:True
CVE-2016-10234 ipa_nat_dma_cmd 576 match_reg_set:x0,x0 trim_non_tail_roots:True
// ...
计算每个cve patch中每个change的签名信息：准备一个patch过的kernel img、symbol、vmlinux，计算ext_list中的每一条对应的签名信息。
验证sig的有效性（match_sig.py mode0）：将sigs和未patch的kernel和patch的kernel 做match（match_sig.py mode0），比较输出结果（match_res_angler_img_20160513_1528152449_m0和match_res_angler_img_20170513_1528152555_m0）。调用res_analyzer，来获取有效的sig，保存在sig_list_1中，判断是否有效的原理是：如果在未patch中没有匹配（0），在patch中匹配了（1），说明当前的sig是有效的，可以用来匹配target kernel。
match匹配target kernel（match_sig.py mode1）：根据sig_list_1中的有效的sig，调用match_sig.py mode1来 match target kernel。match结果保存在match_res_image-G9300-160909_1528162862_m1中，N表示未patch的，P表示patch的。检测结果如下：
CVE-2016-10230 N 224.17
CVE-2016-10232 N 1.16
CVE-2016-10234 N 47.21
CVE-2016-2059 P 1.08
CVE-2016-2066 P 11.21
CVE-2016-2068 P 8.74
CVE-2016-2184 N 7.07
CVE-2016-2489 P 2.40
CVE-2016-2501 P 2.83
CVE-2016-2502 N 13.96
CVE-2016-2546 P 0.36
CVE-2016-3813 N 7.80
CVE-2016-3858 N 3.59
CVE-2016-3866 N 18.39
Time: 349.980788469
可以发现，扫描漏洞的核心在于提取cve patch的change特征，根据特征计算有效的sig，验证sig后match target kernel。提取特征的过程很好理解，但是如何根据特征计算sig以及如何验证时sig是否在target kernel中实现？这就得继续看代码了。
对于智能终端设备/嵌入式设备/云主机厂商而言，这个工具仅仅是为了知道当前有哪些cve未patch而已，最佳的低成本的防御方案就是升级kernel。对于攻击者而言，简单粗暴的方案是根据目前已有的、好用的poc来查看是否可以影响该目标设备。如果连poc都没有，知道了哪些cve未被patch的需求也不大。
