Nynaeve

One of the things that I do when I set up Windows on a new (modern) box that I am going to use for more than just temporary testing is to enable no-execute (“NX”) support by default. Preferable, I use NX in “always on” mode, but sometimes I use “opt-out” mode if I have to. It is possible to bypass NX in opt-out (or opt-in) mode with a “ret2libc”-style attack, which diminishes the security gain in an unfortunately non-trivial way in many cases. For those unclear on what “alwayson”, “optin”, “optout”, and “alwaysoff” mean in terms of Windows NX support, they describe how NX is applied across processes. Alwayson and alwaysoff are fairly straightforward; they mean that all processes either have NX forced or forced off, unconditionally. Opt-in mode means that only programs that mark themselves as NX-aware have NX enabled (or those that the administrator has configured in Control Panel), and opt-out mode means that all programs have NX applied unless the administrator has explicitly excluded them in Control Panel.

(Incidentally, the reason why the Windows implementation of NX was vulnerable to a ret2libc style attack in the first place was for support for extremely poorly written copy protection schemes, of all things. Specifically, there is code baked into the loader in NTDLL to detect SecuROM and SafeDisc modules being loaded on-the-fly, for purposes of automagically turning off NX for these security-challenged copy protection mechanisms. As a result of this, exploit code can effectively do the same thing that the user mode loader does in order to disable NX, before returning to the actual exploit code (see the Uninformed article for more details on how this works “under the hood”). I really just love how end user security is compromised for DRM/copy protection mechanisms as a result of that. Such is the price of backwards compatibility with shoddy code, and the myriad of games using such poorly written copy protection systems…)

As a result of this consequence of “opt-out” mode, I would recommend forcing NX to being always on, if possible (as previously mentioned). To do this, you typically need to edit boot.ini to enable always on mode (/noexecute=alwayson). On systems that use BCD boot databases, e.g. Vista or later, you can use this command to achieve the same effect as editing boot.ini on downlevel systems:

bcdedit /set {current} nx alwayson

However, I’ve found that you can’t always do that, especially on client systems, depending on what applications you run. There are still a lot of things out there which break with NX enabled, unfortunately, and “alwayson” mode means that you can’t exempt applications from NX. Unfortunately, even relatively new programs sometimes fall into this category. Here’s a list of some of the things I’ve ran into that blow up with NX turned on by default; the “No-Execute Hall of Shame”, as I like to call it, since not supporting NX is definitely very lame from a security perspective – even more so, since it requires you to switch from “Alwayson” to “Optout” (so you can use the NX exclusion list in Control Panel) which is in an of itself a security risk even for unrelated programs that do have NX enabled by default). This is hardly an exclusive list, but just some things that I have had to work around in my own personal experience.

1. Sun’s Java plug-in for Internet Explorer. (Note that to enable NX for IE if you are in “Optout” mode, you need to go grovel around in IE’s security options, as IE disables NX for itself by default if it can – it opts out, in other words). Even with the latest version of Java (“Java Platform 6 update 1”, which also seems to be be known as 1.6.0), it’s “bombs away” for IE as soon as you try to go to a Java-enabled webpage if you have Sun’s Java plugin installed.

   Personally, I think that is pretty inexcusable; it’s not like Sun is new to JIT code generation or anything (or that Java is anything like the “new kid on the block”), and it’s been the recommended practice for a very long time to ensure that code you are going to execute is marked executable. It’s even been enforced by hardware for quite some time now on x86. Furthermore, IE (and Java) are absolutely “high priority” targets for exploits on end users (arguably, IE exploits on unpatched systems are one of the most common delivery mechanisms for malware), and preventing IE from running with NX is clearly not a good thing at all from a security standpoint. Here’s what you’ll see if you try to use Java for IE with NX enabled (which takes a bit of work, as previously noted, in the default configuration on client systems):

   (106c.1074): Access violation - code c0000005 (first chance)
   First chance exceptions are reported before any
   exception handling.
   This exception may be expected and handled.
   eax=6d4a4a79 ebx=00070c5c ecx=0358ea98
   edx=76f10f34 esi=0ab65b0c edi=04da3100
   eip=04da3100 esp=0358ead4 ebp=0358eb1c
   iopl=0         nv up ei pl nz na pe nc
   cs=001b  ss=0023  ds=0023  es=0023  fs=003b
   gs=0000             efl=00210206
   04da3100 c74424040c5bb60a mov dword ptr [esp+4],0AB65B0Ch
   0:005> k
   ChildEBP RetAddr  
   WARNING: Frame IP not in any known module. Following
   frames may be wrong.
   0358ead0 6d4a4abd 0x4da3100
   0358eb1c 76e31ae8 jpiexp+0x4abd
   0358eb94 76e31c03 USER32!UserCallWinProcCheckWow+0x14b
   [...]
   0:005> !vprot @eip
   BaseAddress:       04da3000
   AllocationBase:    04c90000
   AllocationProtect: 00000004  PAGE_READWRITE
   RegionSize:        000ed000
   State:             00001000  MEM_COMMIT
   Protect:           00000004  PAGE_READWRITE
   Type:              00020000  MEM_PRIVATE
   0:005> .exr -1
   ExceptionAddress: 04da3100
      ExceptionCode: c0000005 (Access violation)
     ExceptionFlags: 00000000
   NumberParameters: 2
      Parameter[0]: 00000008
      Parameter[1]: 04da3100
   Attempt to execute non-executable address 04da3100
   0:005> lmvm jpiexp
   start    end        module name
   [...]
       CompanyName:  JavaSoft / Sun Microsystems
       ProductName:  JavaSoft / Sun Microsystems
                     -- Java(TM) Plug-in
       InternalName: Java Plug-in für Internet Explorer

   (Yes, the internal name is in German. No, I didn’t install a German-localized build, either. Perhaps whoever makes the public Java for IE releases lives in Germany.)

2. NVIDIA’s Vista 3D drivers. From looking around in a process doing Direct3D work in the debugger on an NVIDIA system, you can find sections of memory laying around that are PAGE_EXECUTE_READWRITE, or writable and executable, and appear to contain dynamically generated SSE code. Leaving memory around like this diminishes the value of NX, as it provides avenues of attack for exploits that need to store some code somewhere and then execute it. (Fortunately, technologies like ASLR may make it difficult for exploit code to land in such dynamically allocated executable and writable zones in one shot. An example of this sort of code is as follows (observed in a World of Warcraft process):

   0:000> !vprot 15a21a42 
   BaseAddress:       0000000015a20000
   AllocationBase:    0000000015a20000
   AllocationProtect: 00000040  PAGE_EXECUTE_READWRITE
   RegionSize:        0000000000002000
   State:             00001000  MEM_COMMIT
   Protect:           00000040  PAGE_EXECUTE_READWRITE
   Type:              00020000  MEM_PRIVATE
   0:000> u 15a21a42
   15a21a42 8d6c9500       lea     ebp,[rbp+rdx*4]
   15a21a46 0f284d00       movaps  xmm1,xmmword ptr [rbp]
   15a21a4a 660f72f108     pslld   xmm1,8
   15a21a4f 660f72d118     psrld   xmm1,18h
   15a21a54 0f5bc9         cvtdq2ps xmm1,xmm1
   15a21a57 0f590dd0400b05 mulps   xmm1,xmmword ptr
              [nvd3dum!NvDiagUmdCommand+0xd6f30 (050b40d0)]
   15a21a5e 0f59c1         mulps   xmm0,xmm1
   15a21a61 0f58d0         addps   xmm2,xmm0
   0:000> lmvm nvd3dum
   start             end                 module name
   04de0000 0529f000   nvd3dum
       Loaded symbol image file: nvd3dum.dll
   [...]
       CompanyName:      NVIDIA Corporation
       ProductName:      NVIDIA Windows Vista WDDM driver
       InternalName:     NVD3DUM
       OriginalFilename: NVD3DUM.DLL
       ProductVersion:   7.15.11.5828
       FileVersion:      7.15.11.5828
       FileDescription:  NVIDIA Compatible Vista WDDM
             D3D Driver, Version 158.28 

   Ideally, this sort of JIT’d code would be reprotected to be readonly after it is generated. While not as severe as leaving the entire process without NX, any “NX holes” like this are to be avoided when possible. (Simply slapping a “PAGE_EXECUTE_READWRITE” on all of your allocations and calling it done is not the proper solution, and compromises security to a certain extent, albeit significantly less so than disabling NX entirely.)

3. id Software’s Quake 3 crashes out immediately if you have NX enabled. I suppose it can be given a bit of slack given its age, but the SDK documentation has always said that you need to protect executable regions as executable.

Programs that have been “recently rescued” from the No-Execute hall of shame include:

1. DosBox, the DOS emulator (great for running those old games on new 64-bit computers, or even on 32-bit computers where DosBox has superior support for hardware, such as sound cards, compared to NTVDM. The current release version (0.70) of DosBox doesn’t work with NX if you have the dynamic code generation core enabled. However, after speaking to one of the developers, it turns out that a version that properly protects executable memory was already in the works (in fact, the DosBox team was kind enough to give me a prerelease build with the fix in it, in leui of my trying to get a DosBox build environment working). Now I’m free to indulge in those oldie-but-goodie classic DOS titles like “Master of Magic” from time to time without having to mess around with excluding DosBox.exe from the NX policy.
2. Blizzard Entertainment’s World of Warcraft used to crash immediately on logging on to the game world if you had NX enabled. It seems as if this has been fixed for the most recent patch level, though.
3. Another of Blizzard’s games, Starcraft, will crash with NX enabled unless you’ve got a recent patch level installed. The reason is that Starcraft’s rendering engine JITs various rendering operations into native code on the fly for increased performance. Until relatively recently in Starcraft’s lifetime, none of this code was NX-aware and blithely outputted non-executable rendering code which it then tried to run. In fact, Blizzard’s Warcraft II: Battle.net Edition has not been patched to repair this deficiency and is thus completely unusable with NX enabled as a result of the same underlying problem.

If you’re writing a program that generates code on the fly, please use the proper protection attributes for it – PAGE_READWRITE during generation, and PAGE_EXECUTE_READONLY after the code is ready to use. Windows Server already ships with NX enabled by default (although in “opt-out” mode), and it’s already a matter of time before client SKUs of Windows do the same.

This entry was posted on Friday, June 15th, 2007 at 7:29 pm and is filed under Debugging, Security, Windows. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.