Risks of RWX memory pages

Question

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?

Answer 1

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.