问题标签 [data-execution-prevention]

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

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

使用 LLVM-5.0，我实现了一个最小的测试用例，它为在运行时返回 32 位整数“42”的函数创建程序集并执行它。

使用llvm::ExecutionEngine我能够在运行时生成以下代码（使用 gdb 显示）：

调用函数产生

我的工作理论是，LLVM 写代码的内存页是不可执行的。

这真的是 DEP 问题吗？如果是，我怎样才能使 LLVM 中的 JITed 函数真正可执行？

附录：实际测试用例

是否可以检查是否启用了数据执行保护？

是否有与此 CMD 命令相同的功能

并返回这样的东西？