博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【Kernel】浅谈固件漏洞扫描技术框架—fiber
阅读量:4208 次
发布时间:2019-05-26

本文共 2796 字,大约阅读时间需要 9 分钟。

浅谈固件漏洞扫描技术框架—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:

首先设想一下没有fiber时,我们应该如何人工判断kernel中的二进制文件有没有被patch?通常,kernel的漏洞被patch时,通过diff源码的信息,我们可以发现对应的更新的代码。再查看kernel的反汇编/编译代码时,我们可以定位到对应的函数查看是否被patch。这部分工作,fiber是如何自动化实现的呢?

接下来,粗略的讨论一下fiber的工作流程。大概可以分为4步:

  1. 提取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:TrueCVE-2016-10230 qce_aead_req 4491-4492,4499 match_reg_set:x0,x1 trim_non_tail_roots:TrueCVE-2016-10230 qce_aead_req 4491-4493 match_reg_set:x0,x1 trim_non_tail_roots-4491-4492:TrueCVE-2016-10232 mdss_fb_force_panel_dead 602 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouintCVE-2016-10232 mdss_fb_change_dfps_mode 716 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouintCVE-2016-10232 mdss_debug_factor_write 688 match_reg_set:x0,x1,x2,x3 func_existence_test:kstrtouintCVE-2016-10234 ipa_generate_flt_hw_tbl_v2 777-778 match_reg_set:x0,x1,x2,x3 trim_non_tail_roots-778-778:TrueCVE-2016-10234 ipa_generate_flt_hw_tbl_v2 778 match_reg_set:x0,x1,x2,x3 trim_non_tail_roots:TrueCVE-2016-10234 ipa_nat_dma_cmd 576 match_reg_set:x0,x0 trim_non_tail_roots:True// ...
  2. 计算每个cve patch中每个change的签名信息:准备一个patch过的kernel img、symbol、vmlinux,计算ext_list中的每一条对应的签名信息。 

  3. 验证sig的有效性(match_sig.py mode0):将sigs和未patch的kernel和patch的kernel 做match(match_sig.py mode0),比较输出结果(match_res_angler_img_20160513_1528152449_m0match_res_angler_img_20170513_1528152555_m0)。调用res_analyzer,来获取有效的sig,保存在sig_list_1中,判断是否有效的原理是:如果在未patch中没有匹配(0),在patch中匹配了(1),说明当前的sig是有效的,可以用来匹配target kernel。

  4. 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.17CVE-2016-10232 N 1.16CVE-2016-10234 N 47.21CVE-2016-2059 P 1.08CVE-2016-2066 P 11.21CVE-2016-2068 P 8.74CVE-2016-2184 N 7.07CVE-2016-2489 P 2.40CVE-2016-2501 P 2.83CVE-2016-2502 N 13.96CVE-2016-2546 P 0.36CVE-2016-3813 N 7.80CVE-2016-3858 N 3.59CVE-2016-3866 N 18.39Time: 349.980788469

可以发现,扫描漏洞的核心在于提取cve patch的change特征,根据特征计算有效的sig,验证sig后match target kernel。提取特征的过程很好理解,但是如何根据特征计算sig以及如何验证时sig是否在target kernel中实现?这就得继续看代码了。

对于智能终端设备/嵌入式设备/云主机厂商而言,这个工具仅仅是为了知道当前有哪些cve未patch而已,最佳的低成本的防御方案就是升级kernel。对于攻击者而言,简单粗暴的方案是根据目前已有的、好用的poc来查看是否可以影响该目标设备。如果连poc都没有,知道了哪些cve未被patch的需求也不大。

 

 

 

你可能感兴趣的文章
【LKM】整合多个LKM为1个
查看>>
【Kernel】内核热补丁技术揭秘
查看>>
【Error】/usr/bin/env: ‘python’: No such file or directory
查看>>
手工挂载VMware共享目录
查看>>
【Kernel】pid 与 tgid
查看>>
【Error】make LKM时 找不到符号
查看>>
【转载】【C语言】浅析C语言之uint8_t / uint16_t / uint32_t /uint64_t
查看>>
【转载】yum update 自动忽略内核更新
查看>>
【maven】打包jar上传到服务器运行
查看>>
关闭centos wayland
查看>>
【Error】chsh: PAM: Authentication failure
查看>>
【Error】zsh历史记录丢失
查看>>
解析漏洞总结
查看>>
有趣的二进制 读书笔记
查看>>
【Windows C++】调用powershell上传指定目录下所有文件
查看>>
kotlin-android-extensions 插件无效问题
查看>>
经典排序算法--Java实现
查看>>
Java中JRadioButton单选按钮分组方法
查看>>
Java图形界面中单选按钮JRadioButton和按钮Button事件处理
查看>>
小练习 - 排序:冒泡、选择、快排
查看>>