View Single Post
Old 08-12-2007   #15 (permalink)
Andrew McLaren


 
 

Re: Data Execution Prevention with Windows Vista

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote ...
> XP, and presumably Vista, do a sort of ersatz DEP where CPU lacks DEP
> support - a bit like Win95 doing Plug-n-Play for devices on ISA bus,
> How well this works (or breaks) is not knopwn to me, but it does imply
> DEP settings can be a factor even where the system (including imaged
> installations and reference PCs) has never seen a DEP processor.


Correct, that was the so-called "Software DEP" feature, briefly described
here:
http://support.microsoft.com/kb/875352/EN-US/

If an exception is issued in the running process, this feature checks to
make sure that the address of the exception handler is in an executable
page. This prevents the exploit of making an exception jump to injected code
in a data page (eg, a "return to libc" attack). From Visual Studio 2003
onwards, applications can enforce this themselves, by being compiled with
the "/SafeSEH" flag. The Software DEP option in Windows enforces this
execution policy for programs built without "SafeSEH"; and by default "only
limited system binaries" - ie, Windows' own executable code; not user
applications.

So Software DEP isn't really an emulation of Hardware DEP in software - it's
a fundamentally different protection mechanism, albeit in an allied field of
memory protection. Calling them both "DEP" lumps together disparate
features. But since the differences are subtle for most users, it might be a
reasonable simplification.

I don't know what the current Windows build parameters are, but I suspect
Windows in the Vista timeframe would be built with the SafeSEH flag by
default; I'm pretty sure it is built with the /GS flag. But XP pre-dated the
arrival of VS2003, so it needed some architectural assistance. In any case,
Vista also provides Address Space Layout Randomisation (ASLR), which
provides a further layer of protection against "return to libc" attacks.

Software conflicts with DEP by user applications nearly always involve
Hardware DEP.

Warm regards,
--
Andrew McLaren
amclar (at) optusnet dot com dot au


My System SpecsSystem Spec