为什么不能通过“数据执行预防”修复Javascript shellcode漏洞？ [英] why can't Javascript shellcode exploits be fixed via "data execution prevention"?

问题描述

堆喷涂维基百科文章表明，许多javascript漏洞涉及定位shellcode在脚本的可执行代码或数据空间内存中的某处，然后让解释器跳转并执行它。我不明白的是，为什么不能将解释器的整个堆标记为数据，以防止解释器通过DEP执行shellcode？同时，javascript派生字节码的执行将由虚拟机完成，该虚拟机不允许它修改属于解释器的内存（这不适用于似乎执行机器代码的V8，但可能适用于使用某种类型的Firefox字节码）。

The "heap spraying" wikipedia article suggests that many javascript exploits involve positioning a shellcode somewhere in the script's executable code or data space memory and then having interpreter jump there and execute it. What I don't understand is, why can't the interpreter's entire heap be marked as "data" so that interpreter would be prevented from executing the shellcode by DEP? Meanwhile the execution of javascript derived bytecode would be done by virtual machine that would not allow it to modify memory belonging to the interpreter (this wouldn't work on V8 that seems to execute machine code, but probably would work on Firefox that uses some kind of bytecode).

我想上面的声音听起来很微不足道，可能其中很多东西实际上已经完成了。所以，我试图了解推理中的缺陷或现有解释器实现中的缺陷。例如。当javascript要求内存时，解释器是否依赖于系统的内存分配而不是实现自己的内部分配，从而使得分离属于解释器和javascript的内存过于困难？或者为什么基于DEP的方法不能完全消除shellcode？

I guess the above sounds trivial and probably something a lot like that is in fact being done. So, I am trying to understand where is the flaw in the reasoning, or the flaw in existing interpreter implementations. E.g. does the interpreter rely on system's memory allocation instead of implementing its own internal allocation when javascript asks for memory, hence making it unduly hard to separate memory belonging to interpreter and to javascript? Or why is it that the DEP based methods cannot completely eliminate shellcodes?

推荐答案

要回答你的问题我们首先需要定义，数据执行预防，及时编译和 JIT Spraying 。

To answer your question we first need to define, Data Execution Prevention, Just In Time Compilation and JIT Spraying.

数据执行保护是一种安全功能，禁止从非可执行内存区域执行代码。 DEP可以通过硬件机制（如NX位）和/或软件机制通过添加运行时检查来实现。

Data Execution Prevention is a security feature that prohibits the execution of code from a non-executable memory area. DEP can be implemented by hardware mechanisms such the NX bit and/or by software mechanism by adding runtime checks.

及时（JIT）编译器是动态编译器，它将运行时的字节代码转换为机器代码。目标是结合解释代码的优点和编译代码的速度。只有在编译中花费的额外时间可以通过编译代码所期望的性能增益来分摊时，它才应该编译方法。 [1]

Just In Time (JIT) compilers are dynamic compilers that translate byte codes during run time to machine code. The goal is to combine the advantages of interpreted code and the speed of compiled code. It should compile methods only if the extra time spent in compilation can be amortized by the performance gain expected from the compiled code. [1]

JIT spray 是强制JIT引擎写入许多带有嵌入式shellcode的可执行页面的过程。

JIT spraying is the process of coercing the JIT engine to write many executable pages with embedded shellcode.

[....]

例如，一个Javascript语句，例如var x = 0x41414141 + 0x42424242;可能被编译为在可执行映像中包含两个4字节常量（例如，mov eax，0x41414141; mov ecx，0x42424242; add eax，ecx）。 通过在这些常量的中间开始执行，会显示完全不同的指令流。

For example, a Javascript statement such as "var x = 0x41414141 + 0x42424242;" might be compiled to contain two 4 byte constants in the executable image (for example, "mov eax, 0x41414141; mov ecx, 0x42424242; add eax, ecx"). By starting execution in the middle of these constants, a completely different instructions stream is revealed.

[.. ..]

关键的见解是JIT是可预测的，必须将一些常量复制到可执行页面。给定一个统一的语句（例如长和或任何重复模式），这些常量可以编码小指令，然后控制流到下一个常量的位置。 [2]

The key insight is that the JIT is predictable and must copy some constants to the executable page. Given a uniform statement (such as a long sum or any repeating pattern), those constants can encode small instructions and then control flow to the next constant's location. [2]

超出本答案范围的高级技术必须用于查找JIT喷涂块的地址和触发漏洞。

Advanced techniques, beyond the scope of this answer, must then be used to find the address of the JIT sprayed block and trigger the exploit.

现在应该很清楚

如果是攻击者的话代码由JIT引擎生成，它也将驻留在可执行区域中。换句话说，DEP不参与JIT编译器发出的代码的保护。 [3]

If the attacker’s code is generated by JIT engine it will also reside in the executable area. In other words, DEP is not involved in the protection of code emitted by the JIT compiler. [3]

参考文献

[ 1] Java即时编译器的动态优化框架

[2] 口译员利用：指针推理和JIT喷涂

[3] JIT喷洒和缓解措施

这篇关于为什么不能通过“数据执行预防”修复Javascript shellcode漏洞？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！