Hello,

yesterday I happened to stumble on a small piece of code that uses stack execution for running a piece of code inside a remote process. I tried it and it does not work: you get an exception on executing the very first code instruction you inject in the remote process.

The code is a few years old and I suppose now, on a Windows machines with the latest patches, stack execution is not allowed anymore.

I'm attaching the VC++ code project I was talking about to the post. It should only be compiled without debugging symbols.


yaa

Attachments:
Posted on 2007-12-01 14:58:17 by yaa
My guess is that it has something to do with Data Execution Prevention.

(...)DEP prevents code from being run from data pages such as the default heap, stacks, and memory pools.(...)

MSDN
Posted on 2007-12-01 21:38:29 by ti_mo_n
Use VirtualAllocEx to allocate memory which can be executed in target process
Posted on 2007-12-02 03:33:26 by Jupiter
Yes, it is DEP, but not SW but HW provided DEP.

yaa
Posted on 2007-12-02 04:40:01 by yaa
in xp sp2 also afaik you cant make the stack executable, even using virtualprotect...
Posted on 2007-12-02 11:58:59 by evlncrn8

in xp sp2 also afaik you cant make the stack executable, even using virtualprotect...


Interesting - if it's true, Microsoft has made a good decision :)
Posted on 2007-12-02 12:29:32 by f0dder
But only if it is HW DEP. The SW provided DEP only acts to avoid malicious code from taking advantage of exception-handling mechanisms in Windows. The true DEP is provided only by the processor.

yaa
Posted on 2007-12-02 13:41:19 by yaa

But only if it is HW DEP. The SW provided DEP only acts to avoid malicious code from taking advantage of exception-handling mechanisms in Windows. The true DEP is provided only by the processor.

yaa



I am guessing you are talking about the NX (No eXecute) bit that has been added to the recent x86 paging scheme.
Posted on 2007-12-02 14:38:07 by SpooK
It's possible to emulate NX bit in software though, The Owl + friends did that with PaX.
Posted on 2007-12-02 15:36:47 by f0dder
I seem to remember posting about some security issues I'd found in the Shared Memory Object.
Specifically, I was able to execute code in a SMO, even though it was Heap memory.
Seems that when we flag a memory object as Shared, we're throwing out all our interprocess protection mechanisms.



Posted on 2007-12-02 16:03:23 by Homer

I am guessing you are talking about the NX (No eXecute) bit that has been added to the recent x86 paging scheme.


NX? It might be, my machine is running an AMD processor. My machines are one without HW DEP support (Intel) and another one with HW DEP (AMD). On the first the code I posted works fine while on the second an exception is rised as soon as an attempt is made to run an instruction on the stack.


yaa
Posted on 2007-12-03 15:39:14 by yaa
That's what "hardware DEP" is - it uses NX/XD bits to fully disable any execution from pages marked with them. On the other hand, "software DEP" protects only exception handlers. You can try and add the exe you want to run to the DEP's 'exception list' (System Properties -> Advanced -> Performance -> DEP -> add something to the list and click it to add a tick mark next to its name). This way DEP is disabled for a given executable. Check it and you'll be 101% sure if the behavior you described is because of the hardware DEP.
Posted on 2007-12-03 18:24:38 by ti_mo_n
Does software DEP only protect exception handlers even when it's configured for all apps and not just system services? I don't have any machines without NX support, so I can't really test... and I'm too lazy to write a driver to turn off NX bit support :)
Posted on 2007-12-03 18:34:30 by f0dder
That's what I've read somewhere. I'll try to write some test app when I get free time, 'cause I'm kinda curious ^^
Posted on 2007-12-03 22:19:24 by ti_mo_n
Hey f0dder,

Here's an article on DEP, both software and NX bit, as well as a demonstration of the holes in software DEP.

http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm

Donkey
Posted on 2007-12-04 04:04:52 by donkey
SW DEP automaticly disables( by ZwSetInformationProcess) if executable image has section called ".aspack" or ".sforce". See LdrpCheckNXCompatibility and LdrpCheckNxIncompatibleDllSection
Posted on 2007-12-19 11:48:53 by seeq
The compatibility hoops Microsoft has to go through because of dirty programmers, *sigh*
Posted on 2007-12-20 09:00:06 by f0dder
Well, perhaps they shouldn't hire them :)
Posted on 2007-12-22 07:05:25 by Homer

Well, perhaps they shouldn't hire them :)

Perhaps they should drop the compatibility hoops and tell third-party developers to play by the rules or have software that breaks.
Posted on 2007-12-22 07:37:30 by f0dder

Perhaps they should drop the compatibility hoops and tell third-party developers to play by the rules or have software that breaks.


Why not just ask them to commit business suicide?

Companies that repeatedly throw aay compatability include:

Apple and Sun

...what great market share they have...

Posted on 2007-12-22 11:09:45 by Rockoon