Does DEP/NX affect web applications?
A while a go when I posted about the .NET Framework 3.5 and 2.0 SP1 being available for download, Kima posed an interesting question in the comments. Kima asked whether the new enforcement of NX compatability by the C# compiler after the application of 2.0 SP1 would affect ASP.NET applications? Specifically - is aspnet_wp.exe declared as NX compatible or not?
First of all a few things need explaining. Number one, what is NX?
Well, NX is all about providing one more tool in the armoury to try and prevent malicious code from executing. Strictly speaking here, we are talking about Data Execution Prevention (DEP) which is a feature of Windows that will trigger a special exception if the CPU tries to execute any machine instructions in pages of the virtual address space that are not meant to contain any executable code. Now some CPU architectures provide support for this "out of the box" whereas some don't. And if yours doesn't, certain versions of Windows (since round about Windows XP SP2) implement DEP in software instead.
A detailed description of DEP can be found here:
Now this question centres around the fact that the default DEP configuration for Windows is OptIn. Only those processes that declare themselves as having been made compatible with DEP have it applied to them.
So how does a process declare itself as being compatible with DEP? This boils down to having the appropriate bit set in the PE header for the EXE itself. That's it. One little bit is all it takes. The bit in question is in the DllCharacteristics field of the IMAGE_OPTIONAL_HEADER structure. The bit that has to be set is 0x100 which has the symbolic name IMAGE_DLLCHARACTERISTICS_NX_COMPAT. How can this be set? Well, normally it would be set by the linker when it generates the image although theoretically you could set it post link using EDITBIN.
Now after you install .NET Framework 3.5 or apply 2.0 SP1, the C# compiler (csc.exe) is updated such that the images it produces have this bit set. Now managed assemblies are themselves always NX_COMPAT (provided they are using safe code at least) but if they use any non NX_COMPAT DLLs this could cause a problem.
But what about web applications? Well, when you run your web application your code is hosted inside either w3wp.exe (IIS6/7) or aspnet_wp.exe (IIS5/IIS5.1(XP)/IIS6-in-5.0-compat-mode). All you need to do to find out if an EXE is marked as NX_COMPAT is use dumpbin.exe to examine the appropriate bit of the PE header:
E:WINDOWSMicrosoft.NETFrameworkv2.0.50727
>dumpbin /headers aspnet_wp.exe | find "DLL characteristics"
8000 DLL characteristics
E:WINDOWSMicrosoft.NETFrameworkv2.0.50727
>filever aspnet_wp.exe
--a-- W32i APP ENU 2.0.50727.1433 shp 33,280 10-24-2007 aspnet_wp.exe
So, the "DLL characteristics" of aspnet_wp.exe in 2.0 SP1 (version .1433) does not include the 0x100 bit. Therefore it is not "opting in" to DEP. And the same goes for w3wp.exe and dllhost.exe:
E:WINDOWSSysWOW64
>dumpbin /headers dllhost.exe | find "DLL characteristics"
8000 DLL characteristics
E:WINDOWSSysWOW64
>dumpbin /headers inetsrvw3wp.exe | find "DLL characteristics"
8000 DLL characteristics
Well, these are all "generic host processes". Their role in life is to act as a host process for application code, from 10 year old ASP applications using VB6 DLLs and legacy third party components through to cutting edge ASP.NET 3.5 AJAX and LINQ enabled applications. If we marked the EXE as NX_COMPAT then DEP would be applied to these processes and many of these older applications would break.
One interesting point to note is that in Windows Vista SP1, Windows XP SP3 and Windows Server 2008 we have added some new APIs (which Michael Howard blogged about the other day) that allow a process to set the DEP policy for itself. The interesting thing is that on of the options is to enable DEP for the process but disable ATL thunk emulation which was the main reason that older ATL components did not sit comfortably with DEP.
So if you are happy that all the components in your web application(s) are compatible with DEP (and that is a big 'if') then you might be able to use these new APIs to enable DEP. Now I cannot confirm whether this is officially supported or recommended by Microsoft for web application in general or ASP.NET applications in particular but it is an interesting idea.
So the answer to the original question, "Does NX affect web applications?", is, I think, no. The host process is not marked NX_COMPAT so on most 32-bit systems with a default configuration DEP will not apply to the process hosting your web application. Assemblies compiled as part of the ASP.NET dynamic compilation will of course get compiled by the C# compiler (if the use C#) so if 2.0 SP1 is present (which it always is if you are using 3.5) those assemblies are marked with NX_COMPAT:
K:nxtestClassLibrary1ClassLibrary1binDebug
>dumpbin /headers ClassLibrary1.dll | find "DLL characteristics"
540 DLL characteristics
But, because they are loading into a process that is not opting in for DEP, DEP will no be applied since it applies at the process level not the assembly level.
Now, one thing I have not checked yet is whether w3wp.exe is marked as NX_COMPAT in Windows Vista and Windows Server 2008. But that will have to wait for another day....
HTH
Doug