On Sat, 20 Aug 2005 22:04:02 -0700, "bryan"

OK... I think we see the trend here; usually new versions from vendors
to fix issues with DEP. So what I'd do is:
- build a list of what software's running on the box
(especially underfootware)
- test suppressing these in MSConfig
- if offender's identified, check that vendor's FAQs etc. on DEP
- stay off the 'net while firewall and av are disabled

I just need some clarification on your suggestion. DEP was shutting down
notepad, wordpad, word and Access. When I disabled DEP for IE, all programs
worked fine. Before disabling DEP, I created a notepad file with 2 lines: abc
and 123. I saved it and re-opened it. DEP then shut it down.

OK

If DEP is supposed to detect code of malware

No, that's the intended application of DEP, but that's not what DEP
does - it's what we imply from what it does.

At a hardware level, it's possible to tell whether a processor is
reading instructions or data from RAM - or to put it another way,
whether a byte that's read from RAM is going into the program register
that interprets it as code, or some other register that will treat it
as data. It's the difference between being touched by a spider's
foot, or the spider's mandables.

Since the days on DOS, programs were supposed to store data in data
segments in RAM, and code in code segments. It was considered bad
programming practice to mix data and code in the same memory segment,
or write "self-modifying" code, i.e. where a program writes different
instructions into memory and then runs into them and runs them.

But you know what it's like; we aren't supposed to drive on pavements
but sometimes we take a short cut or two, or park there for a while.

This creates opportunities for malware to break the rules, i.e. enter
a system ostensibly as "just data", and yet end up being run as raw
code, if they happened to be shaped right. Think of the way we catch
fish on baited hooks... if there's a mix of code and data, and my
"data" is big enough to run over the next part which is code, then
eventually when the processor hits that, it will run me as code.

Once I get control, then that exploit code has to enter the body of my
code, which is probably held in an area of RAM that's supposed to be
for data. It is here that DEP steps in and says "that's not allowed".

At least, that's how I think it works... I'd have preferred it to
block whatever wrote that spiky data into code space, but AFAIK that's
not what it does. Anyway, the effect is similar to pavements suddenly
being mined, so whenever sloppy programmers take a "short cut", they
get caught out by DEP.

The other problem is that certain types of code need to break the
rules that DEP enforces, or rather, it used to be SOP for them to do
so and now they have to change the way they work. This is where av
comes in - because malware code can evade signature recognition in
various ways, an av might sample some code into its own data space,
break it up into short runs that are safe to run, one piece at a time,
and then run it there. If that is seen as "running code in data
space" by DEP, then DEP will stomp on that too.

So - we have situations where software can fall foul of DEP without
any actual malware being involved at all.

Why notepad, wordpad, word and Access? Either due to some shared code
library common to all of them (i.e. DLLs like Riched.dll, MSVCRT.DLL,
MFC42.DLL etc. that are built into the programming language support
code that they were written in), or antivirus activity that arises in
the course of what these apps do.

For example, common to all of these may be MS Office "data" file
formats. MS Office is notorious for bringing auto-running macros into
"data" files, thus single-handedly creating the space for a whole new
generation of malware to play in. Every MS Office data file type can
pose this risk, including Access's .mdb "database" files and Word's
..doc "document" files. If the av sees a .doc being touched, whether
it's by Word, Wordpad or Notepad, it will take an interest.

Macro languages such as used in scripts, HTML and MS Office "data"
files are all interpreted, and are simple to write. That means
wherever the malware goes, it goes in editable form; it's easy to
change it a bit and perhaps cause signature-matching to fail. So it's
easy to see that av might "run" these things to look for malicious
behavior, rather than just read it as data and compare it to mugshots.

But DEP wouldn't kick in if the av was parsing these things as macros,
because macros are interpreted in software, not "eaten" by the
processor as raw code. Think of being picked up by a spider's leg
(data access) and then dropped into its mandables :-)

In any event, I'd try these tests:
- DEP on, but testing in Safe Mode
- DEP on, testing with full MS Config suppression
- DEP on, normal Windows, but av disabled (be offline)
- DEP on, normal Windows, av active as usual (should fail)

If all of those fail, I'd suspect an issue within common shared code
libraries - and you may find a damaged .DLL (e.g. that was "fixed" by
AutoChk) that's involved, with DEP as simply the messenger.

If everything works as long as the av's off, then check av vendor for
a patch. When we first saw these issues with SP2, only AMD had
processors supporting DEP - that's why experience with Dell may not
expose you to this, at first - but now Intel has DEP support as well.

There are broadly three kings of DEP: AMD's NX (No eXecute), Intel's
new equivalent of NX, and "software DEP" that relies on MS's software
logic to figure out what's going on. I don't think these can be
selectively disabled, but they may fail in different ways - and if so,
with Intel being the newest, we may see new failure patterns.

If you really feel that I could be infected despite the fact that
everything is working fine, I am happy to conduct more tests.

I don't think you're infected, so much as in the teeth of an
incompatibility. It's also possible that a broken .DLL was causing a
wild jump into data space that hit a RET (Return) statement and
carried on working before, but now gets caught in data space by DEP.

Please be kind enough to be as non-technical as possible.

Ooops

And thank you very much for your support. Bryan

Thanks! That will make Leythos's flameage easier to bear :-)

"Leythos" wrote:
says...

IOW, if those 1000 PCs are all in one corporate network with
tightly-controlled settings, aopps, the same av rolled out throughout
the organisation, same hardware vendors, etc. then there may be plenty
of configurations you haven't had experience with.

My experience and depth is based on hundreds of different
sites/installations over the last X years. I includes about 90 different
platform setups (hardware/software/apps/security/av....) at this time
and grows every week.

Not to mention all of the friends/family I support what are not in
controlled environments by their own choice.

I'm working full time with PCs too, but I don't build AMD (I like the
CPUs, but most of the motherboard chipsets give me the creeps) and so
I've yet to see any DEP issues first hand. I've come across them when
other folks have raised them - at which point I could have either said
"bah humbug, I've never seen that" or I could say "tell me more".

Intel's doing DEP now, and even the humble Celerons are now doing the
64-bit support thing these days. So soon, I may be personally
elightened... lucky me :-/



-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
-------------------- ----- ---- --- -- - - - -