RWX内存页的风险
对此答案收到负面评论后 - 我可以在不使用寄存器的情况下在.text区域中实现计数器吗？，我进行了一些调查，试图了解RWX内存页是否真的是不常见且罕见的东西，或者每个流行的节目都有一些。 （科学！）
我通过 WinDBG 附加到 MSVS，已执行 !address /f:Image,PAGE_EXECUTE_READWRITE,
我看到了很多这样的行：
7a534000 7a537000 3000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE Image "C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\6836a951700c2eb01a933212425cda4e\System.ni.dll"
我检查了它的部分，并且有 .xdata 部分带有“执行读写”标志。
这是否意味着每个加载了 .NET 库的应用程序都具有 RWX 内存页？例如，您的浏览器（如果您运行 Windows）。（幸运的是，FF8 和 IE8 都不使用 .NET）
那么我们为什么要担心 RWX 内存呢？
After getting negative comments on this answer - can i implement counter in the .text area without using registers?, I performed a little investigation, trying to understand if RWX memory pages are really non-usual and rare thing, or every popular program has some. (Science!)
I attached to MSVS by WinDBG, executed !address /f:Image,PAGE_EXECUTE_READWRITE,
and I saw a lot of lines like this:
7a534000 7a537000 3000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE Image "C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\6836a951700c2eb01a933212425cda4e\System.ni.dll"
I examined its sections, and there is .xdata section with "Execute Read Write" flags.
Does it mean that every application, with a .NET library loaded in it, has RWX memory pages?Your browser, for example (if you run Windows). (Fortunately, neither FF8, neither IE8 don't use .NET)
So why do we bother about RWX memory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的直觉是这可能不是问题。这可能是运行时环境支持动态行为所必需的。
可写和可执行的内存区域存在安全问题。这允许攻击者使用 shellcode 填充缓冲区，然后执行此代码。用 shellcode 填充缓冲区并不是什么大问题，它只是数据。当攻击者能够控制指令指针（EIP）时，问题就会出现，通常是通过使用基于堆栈的缓冲区溢出来破坏函数的堆栈帧，然后通过将该指针分配给 shellcode 的地址（或nop sled 中的某处将命中 shellcode）。
如果您想更好地了解此安全措施，请查看 NX 位出现之前的缓冲区溢出漏洞。您应该阅读经典论文Smashing the Stack for Fun and Profit。请记住，由于 NX 位、ASLR 和金丝雀，这些攻击都不再有效。
My gut feeling is that this probably isn't a problem. This is probably required by the run time environment to support dynamic behavior.
There is a security problem with memory regions that are both writable and executable. This allows an attacker to fill a buffer with shellcode, and then execute this code. Filling a buffer with shellcode isn't a big deal, its just data. The problem arises when the attacker is able to control the instruction pointer (EIP), usually by corrupting a function's stack frame using a stack based buffer overlfow, and then changing the flow of execution by assigning this pointer to the address of the shellcode (or somewhere in the nop sled which will hit the shellcode).
If you want to understand this security measure better, then take a look at what buffer overflows exploits where like prior to the advent of the NX bit. You should read the classic paper, Smashing the Stack for Fun and Profit. Keep in mind that none of these attacks work anymore because of the NX bit, ASLR and canaries.