关于DEP、ASLR的兼容性问题分析

---

DEP带来的兼容性问题

---

一、硬件方面

不具有DEP技术支持的CPU将无法从硬件层面对内存页进行保护从而应用DEP，在此情况下，软件支持的DEP并不能直接阻止在数据页上执行代码。

二、内核方面

32位系统只能通过引导至PAE模式来支持DEP，并不能通过PTE的高双字的最高bit即bit63来实现（PTE的第63位控制着页的可执行属性）。

即这个位置为0，表示此页不可执行；没有置为0，表示此页可以执行。

而32位系统的页目录和页表项只有32个bit，所以不可能提供DEP的这个保护位，因此DEP只有在64bit的PTE上才能实现。

而只有cr4的bit5即PAE启用的时候，PTE才为64bit。

三、功能方面

用于将内存位置标记为不可执行的DEP，会导致32位软件出现兼容性问题。

这是因为DEP阻止了某些程序的运行，可能会导致这些应用程序被挂起而产生无法运行的错误。

---

ASLR带来的兼容性问题

---

一、内核方面

在Windows的32位系统与64位系统中，其地址随机化的位数与方式均是不同的。

在32位系统中，Windows只尝试随机化32位地址中的8位，这些是位从16到23，只影响地址的页目录条目和页表条目部分。

原因是操作系统不能简单地将地址的任意位随机化，在页面部分(0到11位)中随机分配偏移量将打破程序对数据对齐的假设。

页面目录指针（位30和31）也不能被更改，因为第31位是为内核保留的；而第30位被物理地址扩展用作存储体交换技术，以寻址2 GB以上的RAM，这使得32位地址中的14位不能被随机化。

而在64位系统中，Windows对64位程序的基地址随机化程度会更高，从而使攻击64位程序的难度比攻击完全相同程序的32位版本的难度高上数百倍。

故将32位代码重新编译为64位会大大增加可供地址空间布局随机化选择的基本地址数量，也可以大大提高其抗攻击能力。

二、硬件方面

ASLR无法在部分较落后的硬件上保障其保护能力。

首先，处理器有个称为内存管理单元(MMU)的部件，负责映射计算机在内存中存储程序的地址。为跟踪这些地址，MMU频繁查询名为页表的目录。

而VUSec攻击（disclosed in 2017）的关键，在于设备通常将页表存储在处理器缓存中——让最常访问的信息随时可被计算核调用的一小块内存。这种做法可以提升芯片处理速度和效率。

但是，网页上运行的一段恶意JavaScript代码，同样可以写入那块缓存。最关键的是，它还能同时查看MMU的工作速度。

通过密切监视MMU，JavaScript代码可以找出其自身地址——攻击代码会复写缓存，一次一个单元，直到看到MMU降速，MMU要执行4次单独的页表查询，才能找到任给代码段的物理地址。

因此，该攻击会重写缓存4次，搜出缓存中存放页表的4个地方。每一次，恶意程序都会记下MMU降速的时刻。

MMU走到该降速时刻的耗时，就成为了恶意代码自身在缓存中地址的提示信息，当设备将攻击代码从缓存中拷贝到RAM中时，ASLR想隐藏起来的代码内存地址就暴露无遗了。

因此，若要彻底的防范ASLR攻击，完全修复该硬件漏洞最终将需要更换硬件，而非软件。设备将需要建立在重新设计的新架构之上的新芯片——MMU与处理器缓存中的页表相互隔离。

三、后注

该漏洞于2017年初被阿姆斯特丹自由大学的研究员Ben Gras和他的同事Kaveh Razavi披露，使得ASLR在不同硬件设备上的表现能力产生差异（至少2017年以前生产的硬件均无法较好地防御该漏洞）。

而此后较为完善的ASLR保护机制很可能无法作用于这些较为老旧的芯片。