(原文链接: BootStomp: On the Security of Bootloaders in Mobile Devices)
7 Evaluation
这一部分讨论对应用在来自商业手机设备的bootloader的BOOTSTOMP评估。尤其是,对它们中的每一个,我们运行分析工具来定位在第6章讨论的两类漏洞。在第一个实验中,我们使用工具自动发现潜在的路径 ,从攻击者控制的数据(例如,flash 内存) 到代码中能引起内存破坏缺陷的位置。第二个实验,我们使用工具来发现关于锁定/解锁机制如何实现的潜在的漏洞。我们在一台126GB内存的12核运行ubuntu 16.04 的intel机器上运行所有的实验。
我们首先讨论我们使用的bootloader的资料集,结果的分析,和几个用例的深入(in-depth)探讨。
7.1 资料集
为了这个工作,我们考虑了5种不同的bootloader。 这些设备代表3种不同的芯片集家庭:华为 P8 ALE-L23(华为/海思 芯片集), 索尼Xperia XA(MediaTek 芯片集)和 Nexus 9 (NVIDIA Tegra 芯片集)。我们同样也考虑高通开发的两个版本的基于LK的bootloader。尤其是,我们考虑一种老的版本的高通的LK bootloader(它因包含一个安全缺陷而众所周知,CVE-2014-9798 [19]),和它的最新可获得版本(根据官方的 git 库[22])。
7.2 发现内存破坏
我们用BOOTSTOMP去分析在我们资料集中的五种bootloader 来发现内存破坏漏洞。这些漏洞能导致任意的代码执行或者拒绝服务攻击。 表2 总结了我们的发现。尤其,表中展示了在每个 bootloader 中识别出来的seed, sink和入口点的数量。表中也展示了为每个 bootloader的筹集的警告数量。由于(out of) 总数36个,对它们中的12个来说,这个工具识别了从一个源头到类似memcpy 的sink的一个潜在的路径,它导至一个buffer overflow的潜在可能。这个工具抛出5个关于一个污点变量被间接引用的可能性的警告,它们能依次构成(constitute)一个内存破坏bug。最终,它们中的19个,这个工具识别出,污点数据能够到达一个循环的控制条件语句,这可能导致拒绝服务器攻击。我们然后手动调查(investigate)所有的警告,来确定是否这个工具没有覆盖安全漏洞。我们手动调查透漏(reveal)总计7个安全漏洞, 他们的六个是以前未知的(5个已经被各自的(respective)供应商确认),然而剩下的一个是以前已知的 CVE-2014-9798 ,它影响到一个高通的老的基于LK 的bootloader。注意,因为BOOTSTOMP 提供一系列基本块,它和相关的污点seed和sink组合成污染踪迹,即使是对不那么熟练的分析者,手工检查(inspection)也变得容易和快速。我们也注意到,因为在angr中和ARM的THUMB模式指令分析相关的bug,MediaTek bootloader不能被正确的处理。
这些结果说明(illustrate)一些关于BOOTSTOMP的可扩展性和可能性的有趣的点。第一,我们注意到, 每一个入口点的运行耗时(elapse)平均少于5分钟(持续在每个EP纵列), 发现了总共7个bug。我们用40分钟的时间限制,运行了一些列相同的实验。尽管如此(nonetheless),我们注意到没有额外的警告产生。这两个结果令我们相信十分钟的超时(也就是,2倍于平均分析时间)是合理的。第二,在针对LK bootloader测试我们的工具时,我们记下来一个内存消耗(consumption)的峰值(peak)。调查后,我们发现LK 是资料集中唯一一个有知名的头(ELF)的bootloader,这允许我们对属于.data和.bass段的字节无约束,就像在 第6章规定的。第三,我们注意到,被报出的所有警告的数量是十分少的,甚至在没有调试信息或者其他逆向工程信息的情况下操作,也是在人类分析师能够合理分析它们的范围内。最后,正如我们在表中展示的,对一个相同的潜在的(underlying)漏洞多于一个警告被触发。针对同一个漏洞的多重(multiple)警告的出现,是给一个问题的分析者的强烈指示(indicator)。这发生在当超过1个 seed 属于(fall within)产生唯一bug的相同路径时,例如(for instance),当超过1个污染的参数存在于类似memcpy的函数调用时。
出于这种考虑(with this in mind),并且通过观察表,你可以看到污染 的路径的38.3%左右真正地代表真实的漏洞。同时也注意,在污染路径上下文中,没有报告的警告是误报(也就是,没有污染的路径),然而,误报在理论上(theoretically)是可能的,像7.4部分讲的那样。
我们的工具在华为的android bootloader上 发现了(uncover)5个新的漏洞。首先,当解析保存在boot分区中的linux kernel的设备树(DTB)时,一个任意内存写操作或者拒绝务器能发生。第二,当读root可写的oem_info 分区时一个heap buffer overflow会发生,这是由于没有检查num_records字段。另外,有root权限的用户能够向nve和oem_info分区写,能从这些分区读到配置数据和控制手机外设的内存访问的权限。剩下的两个漏洞会在下面描述细节。
不幸的是,由于华为 bootloader的的架构,正如在3.1部分详述的,这些漏洞在整台设备的安全的影响是相当严重的。因为这个bootloader 运行在EL3,并且负责几乎(virtually)所有设备组件的初始化,包括调制解调器(modem)的基带(baseband)固件和安全的OS,这个漏洞将不仅允许你打破信任链,并且它也将会组成一个手段(mean)来建立(establish)在设备上的存留(persistence),这是不容易被用户检测的 (detectable),或者来获得任何其他种类的攻击。华为确认了这些漏洞。
BOOTSTOMP 也发现一个在NVIDIA的hboot 上的漏洞。 hboot 运行在 EL1,这意味着它有和linux kernel 一样在对硬件上相等的 特权,虽然它存在于信任链的早期,并且因此它的危害(compromise)能够导致一个攻击者增加存留。我们已经报告这个漏洞给英伟达,并且和他们一起工作来修复它。
最后,我们重新发现一个以前的漏洞,对高通的 aboot报告的,CVE-2014-9798。这些漏洞允许一个攻击者来执行拒绝服务攻击。然而,这个漏洞已经被提交补丁,并且我们对当前aboot 版本的分析没有产生(yield) 任何警告。
案例研究: 华为内存破坏漏洞。 BOOTSTOMP 产生多重的涉及一个函数的警告,这个函数的原始名字我们相信是叫read_oem()。尤其是,工具突出了这个函数如何从flash 读内容并写到buffer 中。一个手动的调查透露(reveal)这个函数如何易受内存破坏的攻击的。尤其是,这个函数读取整体的(monolithic)用于记录的数据结构,这个结构保存在设备存储中的一个叫oem_info的分区。这个分区包含一些记录,它们都能跨越(span)多重块(block)。每一个块是0x4000字节,其中前512字节构成(constitute)一个头。这个头主要包含以下 4个字段: record_id, 它指明记录的类型;record_len, 它指明记录的总长度;record_num,它知名组成这个记录的块的数量;record_index,它是一个基于1的索引(1-based index)。
漏洞列在以下: 函数将首先扫描匹配record_id的块的分区。 现在, 考虑一个record_num 是2的块, 并且它的record_index 是1. 事实上,record_num是2表明这个记录跨越2个不同 的块。 在这一点上, read_oem 函数假设当前块的长度是最大的,也就是 0x4000,并且,它将因此把这些所有字节拷贝到目的数组,完全忽略作为参数传入的长度值。因此,因为oem_info分区能被攻击者控制,一个攻击者能创建一个特殊的精心制作的(crafted)记录,以至于触发一个缓冲区溢出。不幸的是,这个bootloader用这个分区来存放至关重要的信息,这些信息在每一次启动的最开始被访问,比如bootloader的logo。因此,一个攻击者将能够完全危害bootloader, fastboot和信任链。 结果,它将因此让攻击者安装持久稳固的(persistent)root工具成为可能。
案例研究: 华为任意内存写入 。 我们准备的第二个案例研究是一个任意内存写入漏洞,这个漏洞是我们的工具在华为的 bootloader上识别的。尤其是,这个工具产生一个和read_from_partition 有关的警告。 特别的, 这个工具精确地找到(pinpoint) 以下函数调用(invocation)read_from_partition("boot",hdr->kernel_addr),并且,工具突出显示hdr结构能被攻击者控制。手工调查显示不仅hdr(而且它的字段,包括kernel_addr)能被攻击者完全控制,而且函数实际上从一个被 输入("boot",在这个案例)指定的分区读内容,然后复制到被hdr->kernel_addr指定的地址。由于这个目的地址是攻击者控制的,一个攻击者能依赖这个函数写任意内存(通过修改"boot"分区的内容) 到任意地址,攻击者能把它指向 bootloader它自己。我们注意到,这个漏洞只是在bootloader bei被解锁时可利用,但是,尽管如此,它是一个允许攻击者运行任意代码作为bootloader 它自己的漏洞(并且,不只是作为不安全OS的一部分)。此外,下一部分提供证据,证明至少对这个特定的案例,一个攻击者解锁bootloader是容易的。