Prev: Is GetCurrentThread really a constant?
Next: hid.dll & VC++ 6
From: Ira Baxter on 8 Nov 2008 17:52

"David Craig" <drivers(a)yoshimuni.com> wrote in message
news:%23Lf7reXMJHA.276(a)TK2MSFTNGP02.phx.gbl...
> First let's begin with all the reasons why this is a bad idea:
> 1. Executing code in memory not explicitly marked as containing
executable
> code is what a lot of virus, worms, and other malware do. If you
duplicate
> their techniques, expect some things and people to object.

If I ran viruses, or I ran code that didn't do buffer bounds checking
that downloaded bytes to data area and executed it, yes, people
could reasonably object. For the application I am running,
a) it never downloads code from a source it doesn't trust
(in fact, the application is the only thing that can generate this code),
and it doesn't have the buffer bounds problem; it is coded
in language that checks buffer limits.

I don't mind DEP, I think its a good idea. Like all protection mechanisms,
there needs to be controlled ways to disable it.

> 2. Microsoft has gone big time into their Java Virtual Machine killer,
> .NET. They have no incentive to support the methodology you have used
since
> it in some way competes with them.

I prefer to think that the elephant simply doesn't notice an ant.

> 3. I presume from your comments that you use an allocation function to
> obtain the memory for your buffer. This is a malware technique as is
using
> the stack to execute code.

?? Allocating memory to hold compiled code is a technique that
any dynamically compiled language must use. By this analogy,
..NET is a malware technique. I think the analogy doesn't hold.
IF statements are used by malware, too, and analogy doesn't hold
there either.

> Since the segment registers are not used as
> intended by Microsoft the DEP protection uses page tables to implement it.

Right. So the problem is granularity. There are times when I need
a few hundred bytes, dynamically allocated, to hold generated code.
Setting aside full pages is a complete waste of space.

> Second some possible solutions in random order:
> 1. Change the memory page table entries from data to code.

So, in those places where I can reasonably do that, I'll do that.

> 2. Compile (?) your code to a .NET instruction sequence that you can have
> the .NET runtimes execute.

Then I get the limiting assumptions that come with .NET. This
applicaiton is an alternative language/execution engine that enables decent
parallel programming. At least, that's the claim I am trying to make
and validate. The .NET engine wasn't designed to go parallel,
so any success they have will be bolted on as an afterthought.
I don't believe they'l have good success because of their assumptions.

Let many flowers bloom.

> 3. And, as you said, just don't do it even if you consider it a
> non-solution.

> 4. Use an assembly module to create a chunk of 'code' consisting of NOPs
> that you overlay with your compiled byte sequences as needed.

How does this help? Even an assembler can't mark less-than-a-page
as "executable".

Look, I understand your basic objections. What I was hoping for
was some additional insight into how DEP is controlled.

-- IDB


> "Ira Baxter" <idbaxter(a)semdesigns.com> wrote in message
> news:eq1ektWMJHA.1204(a)TK2MSFTNGP05.phx.gbl...
> > We have long had a robust 32 bit application that loads object code into
a
> > dynamic allocated
> > buffer and executes it. That lights up Data Execution Prevention if
it
> > is
> > enabled
> > when our application is running.
> >
> > It appears until Vista came along, DEP was enabled by default only for
> > "essential system programs and services" (according to the buttons
> > for managing DEP in the control-panel system window).
> >
> > Because our application (quite reasonably) wasn't an essential
> > system service, DEP was not enabled when our application ran,
> > and everything was fine.
> >
> > But it seems like I'm suddenly getting complaints from Vista users.
> > Is the default for Vista different? How do I find out except
> > by opening 100 random Vista systems and inspecting them (ugh)?
> > (We tested on a Vista system inhouse, but much to our chagrin,
> > we just figured out that our test Vista box doesn't have the hardware
> > to support DEP, so it is off on that box no matter what).
> >
> > Under the assumption that DEP was set for Vista, I have done some
> > simple experiments, on an XP system that *does* have hardware
> > support for DEP. Sure enough, when I enable DEP
> > "for all applications except....", our application is stopped.
> > When I add our application image path to the exceptions
> > list, the application runs fine. So, DEP appears to be the problem.
> >
> > If you dig long enough, you discover a bit (/NOCOMPAT) in the .exe
header
> > which encodes whether the application is "compatible with
> > Data Execution Prevention" or not. In an attempt to solve
> > our problem permanently, I tried to set/reset this bit,
> > using MS VS 2005's EDITBIN with the following command line:
> > EDITBIN /NXCOMPAT<option> <ourapp.exe>
> > I tried the option as empty, and as :NO, and after each
> > attempt, transferred the application to the XP system
> > with "DEP enabled for all applications" with no exceptions.
> >
> > The application always failed at the same place.
> > It appears that EDITBIN isn't doing what I expect.
> >
> > Any suggestions on how to get this right?
> > [No, I can't change the application to not execute code].
> >
> > -- IDB
> >
> >
>
>


From: Ira Baxter on 8 Nov 2008 18:18
Next chapter ... below.

"Ira Baxter" <idbaxter(a)semdesigns.com> wrote in message
news:eq1ektWMJHA.1204(a)TK2MSFTNGP05.phx.gbl...
> We have long had a robust 32 bit application that loads object code into a
> dynamic allocated
> buffer and executes it. That lights up Data Execution Prevention if it
is
> enabled when our application is running.
>
> It appears until Vista came along, DEP was enabled by default only for
> "essential system programs and services" (according to the buttons
> for managing DEP in the control-panel system window).
>
> Because our application (quite reasonably) wasn't an essential
> system service, DEP was not enabled when our application ran,
> and everything was fine.
>
> But it seems like I'm suddenly getting complaints from Vista users.
> Is the default for Vista different?

Anybody care to remark on this? Microsoft?

> How do I find out except
> by opening 100 random Vista systems and inspecting them (ugh)?
> (We tested on a Vista system inhouse, but much to our chagrin,
> we just figured out that our test Vista box doesn't have the hardware
> to support DEP, so it is off on that box no matter what).
>
> Under the assumption that DEP was set for Vista, I have done some
> simple experiments, on an XP system that *does* have hardware
> support for DEP. Sure enough, when I enable DEP
> "for all applications except....", our application is stopped.
> When I add our application image path to the exceptions
> list, the application runs fine. So, DEP appears to be the problem.

So, preliminary testing under XP with SP3 shows that I
can set DEP "only for system programs" or enable
for everything with exceptions for specific
executables that I choose. When I log in as administrator,
and I select the application the in question as an
exception, voila, it runs without violating DEP as expected.

Surprise, surprise, having configured this as administrator,
when I log in as a normal user, the DEP appears to
be enabled for *everything*, eg.., no exceptions.
Inspecting the DEP state *as that user* simply
shows a greyed-out box for all the DEP configuration
data, so basically it isn't telling me anything.
Configuring DEP as admin, and having that ignored
as a user, seems to make the DEP configuration
pretty pointless. Am I using it wrong somehow,
or is just stupidly implemented?

> If you dig long enough, you discover a bit (/NOCOMPAT) in the .exe header
> which encodes whether the application is "compatible with
> Data Execution Prevention" or not. In an attempt to solve
> our problem permanently, I tried to set/reset this bit,
> using MS VS 2005's EDITBIN with the following command line:
> EDITBIN /NXCOMPAT<option> <ourapp.exe>
> I tried the option as empty, and as :NO, and after each
> attempt, transferred the application to the XP system
> with "DEP enabled for all applications" with no exceptions.
>
> The application always failed at the same place.
> It appears that EDITBIN isn't doing what I expect.

There's a VS2005 linker option: /NXCOMPAT:NO
documented as follows:

/NXCOMPAT:NO can be used to explicitly specify an executable as
not compatible with Data Execution Prevention

That's pretty strange thing to say. Guessing what it means,
settting this bit means that the linkedit'd program should be
executed with DEP disabled. Well, I set the bit in the
linker (as well as having tried the EDITBIN option).
I tried it as admin with DEP enabled for everything.
Nope, still prevents the program from running.

So, what on earth does /NXCOMPAT:NO actually *do*?
The other (YES) state, implies the program is compatible
with DEP and can be run that way.

While I am working to resolve the DEP issues programmatically
in the application, not being able to understand how to configure
DEP isn't helping with a workaround.

-- IDB

> Any suggestions on how to get this right?
> [No, I can't change the application to not execute code].
>
> -- IDB
>
>


From: Jeroen Mostert on 8 Nov 2008 18:26
Ira Baxter wrote:
[snip]
> Right. So the problem is granularity. There are times when I need
> a few hundred bytes, dynamically allocated, to hold generated code.
> Setting aside full pages is a complete waste of space.
>
If you find yourself generating "a few hundred bytes" often without an
opportunity to reuse memory, write your own allocator that takes memory from
an executable page heap. Or else trust your application completely and mark
every range your regular allocators return as executable when you intend to
use it for code, but since this will leave executable pages all over the
place, it's hardly an elegant solution (and a security risk).

--
J.
From: Jeroen Mostert on 8 Nov 2008 18:27
Ira Baxter wrote:
> So, what on earth does /NXCOMPAT:NO actually *do*?
> The other (YES) state, implies the program is compatible
> with DEP and can be run that way.
>
I answered this question on 2008-10-19. In case you missed my reply, here's
the relevant bit again:

"The MSDN documentation says "/NXCOMPAT:NO can be used to explicitly specify
an executable as not compatible with Data Execution Prevention". This is not
how it works, at least not for XP -- the semantics *might* actually be that
for Vista (that is, your exe's subsystem version is 6.00), but I have no idea.

For XP and earlier, at least, this should say "/NXCOMPAT:NO can be used to
specify an executable as not tested to be compatible with Data Execution
Prevention", because that's the actual inverse of /NXCOMPAT. It merely
*clears* the bit that says the application *is* compatible with DEP, which
does not mean the application definitely is *not* compatible with DEP. If
DEP is set to OptOut, your application must still be added to the list of
exceptions to disable DEP. /NXCOMPAT can be used to opt-in to DEP, but not
to opt-out.

To actually say your application absolutely positively cannot handle DEP and
should get a break, you have to call SetProcessDEPPolicy() from within the
application. This function is only availabe from Vista SP1 onwards, however."

--
J.
 | 
Pages: 1
Prev: Is GetCurrentThread really a constant?
Next: hid.dll & VC++ 6