javascript - 为什么不能通过 "data execution prevention"修复 Javascript shellcode 漏洞？

Question

"heap spraying"维基百科文章表明，许多 javascript 漏洞利用涉及将 shellcode 定位在脚本的可执行代码或数据空间内存中的某个位置，然后让解释器跳转到那里并执行它。我不明白的是，为什么不能将解释器的整个堆标记为“数据”，这样 DEP 就会阻止解释器执行 shellcode？同时，javascript 派生字节码的执行将由不允许它修改属于解释器的内存的虚拟机完成(这在似乎执行机器代码的 V8 上不起作用，但可能在使用某种类型的 Firefox 上起作用字节码)。

我想上面的内容听起来微不足道，实际上可能正在做一些类似的事情。所以，我试图了解推理中的缺陷在哪里，或者现有解释器实现中的缺陷。例如。当 javascript 请求内存时，解释器是否依赖于系统的内存分配而不是实现自己的内部分配，因此很难将属于解释器的内存和属于 javascript 的内存分开？或者为什么基于DEP的方法不能完全消除shellcode？

Answer 1

要回答您的问题，我们首先需要定义数据执行保护、即时编译和JIT Spraying。

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

即时 (JIT) 编译器是动态编译器，可在运行时将字节码转换为机器码。目标是结合解释代码的优点和编译代码的速度。仅当花费在编译上的额外时间可以通过编译代码的预期性能增益来摊销时，它才应该编译方法。 [1]

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

[....]

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.

[....]

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 喷射 block 的地址并触发漏洞利用。

现在应该很清楚了

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] A Dynamic Optimization Framework for a Java Just-in-Time Compiler

[2] Interpreter Exploitation: Pointer Inference and JIT Spraying

[3] JIT spraying and mitigations