Pervasive Defenses


On Windows Vista, Internet Explorer 7 has many defenses designed to protect the user from malicious software and malicious Web sites. Some of these defenses also exist in Internet Explorer 7 on down-level Windows platforms.

User Account Control (UAC) aside, the three prime defenses in Internet Explorer 7 in Windows Vista are:

  • ActiveX opt-in

  • Protected Mode

  • Data Execution Prevention

ActiveX Opt-in

A critical defense in Internet Explorer 7 is ActiveX opt-in. By default, most previously installed ActiveX controls will not run inside Internet Explorer until the user opts to use that control the first time the control is referenced. By disabling most ActiveX controls on the system by default, Internet Explorer reduces the amount of code that can come under attack while still letting a user have the powerful experiences you can get with ActiveX content like Adobe Flash.

Users often have controls on their machines they simply don’t know they have, so the ActiveX opt-in capability brings first use to the attention of the user. The net effect to you as a developer is that when users upgrade their machines to Windows Vista and attempt to use a control your Web application uses, it will fail until they opt to use the control.

image from book
Why Doesn’t Microsoft Just Get Rid of ActiveX Controls?

ActiveX controls are not hard to write, but they can be hard to get right. So why doesn’t Microsoft simply get rid of the technology? First, remember that binary extensibility is part of the HTML standard (W3C 1999). We have thought about removing ActiveX support many times. The problem is that so many companies rely on ActiveX controls to run their businesses, and many common Web components, such as the Adobe Flash Player, are implemented as ActiveX controls. But if you’re thinking of writing new mobile code, and you are considering using ActiveX controls, you should really consider writing the code using .NET. It’s much safer.

image from book

This first-run prompt does not apply to controls that are deployed via a CAB file referenced from the OBJECT tag in the Web page. The user will be prompted for consent to install these controls and will not be prompted again to run.

With that said, it is possible to add your own control to a pre-approved list of ActiveX controls that will not prompt the user on first use. To add your control, simply add a new key under HKLM\Software\Microsoft\Windows\CurrentVersion\Ext\PreApproved; the name of the key is your control’s GUID. You would typically set this key from an elevated install process.

Do not add your control to the pre-approved list if the control is not meant to be used from a Web page, and do not add it to the list if the control has previously been “kill-bitted” (Microsoft 2006a).

Table 6-1 shows the changes made to ActiveX control installation through various versions of Internet Explorer.

Table 6-1: Various ActiveX Scenarios in Internet Explorer
Open table as spreadsheet

Scenario

IE6

IE6 Windows XP SP2

IE7 Windows XP SP2

IE7 Windows Vista

Unsigned ActiveX downloads

Blocked silently

Blocked silently

Blocked silently

Blocked silently

Signed ActiveX downloads

Prompt

Blocked and Info bar notification

Blocked and Info bar notification

Blocked and Info bar notification

Preinstalled ActiveX controls

Run silently

Run silently, policy can be changed

Blocked and Info bar notification

Blocked and Info bar notification, and will prompt for elevation during installation

Now let’s switch focus to developer best practices.

Protected Mode

Of all the defenses in Internet Explorer 7 in Windows Vista, Protected Mode is probably the biggest architectural change–it’s the newest too. Protected Mode relies on Integrity Levels in Windows Vista, which we covered in depth in Chapter 2, “User Account Control, Tokens, and Integrity Levels.” In short, the browser process facing the Internet and rendering all that complex and potentially dangerous markup and code runs at low integrity because the content can never be trusted.

Note 

Protected Mode is an example of defense in depth, but it is not a panacea.

In general, HTML content should not behave any differently when Protected Mode is enabled. Things get a little trickier for extensibility products such as ActiveX controls, toolbars, and browser helper objects that may need to write to the file system or registry. Most, if not all, write operations to the operating system will behave differently when Protected Mode is enabled because Internet Explorer is running at low integrity, and the majority of Windows Vista objects are labeled at medium or higher integrity.

Note 

Protected Mode is disabled if Internet Explorer is started by selecting “Run as administrator.”

Table 6-2 outlines some of the new function calls in Internet Explorer that help extensibility components behave correctly when Protected Mode is enabled. To use these functions you must include <iepmapi.h> and link with iepmapi.lib.

Table 6-2: Internet Explorer 7.0 Protected Mode Helper Functions
Open table as spreadsheet

Function

Comments

IEIsProtectedModeProcess

Determines if IE is running in Protected Mode or not.

IEShowSaveFileDialog

Displays the Save File dialog box. The process that displays the dialog box is not the low-integrity Internet Explorer, it is a sister process running at medium integrity. If the dialog operation succeeds, your code must free the path buffer (lppwstrDestinationFilePath) with CoTaskMemFree.

IEGetWriteableFolderPath

Returns a path the user can write to from Protected Mode.

SHGetKnownFolderPath (FOLDERID_LocalAppDataLow,...)

Technically not an IE API, this function returns the path to the low-integrity application data folder.

IESaveFile

Saves the file selected during the previous call to IEShowSaveFileDialog.

IEGetWriteableHKCU

Returns a handle to a registry location under HKCU writable from low integrity.

IEIsProtectedModeURL

Determines if Protected Mode will be enabled for the URL. By default, sites in the Trusted Sites zone do not have Protected Mode enabled.

IELaunchURL

Launches an instance of Internet Explorer with the correct Protected Mode setting. Use this rather than CreateProcess.

The IEShowSaveFileDialog function is interesting because the dialog is created by a medium-integrity helper process named IEUser.exe rather than by the low-integrity IExplore.exe rendering content from the Internet. The reason for launching the dialog from a higher-integrity process is to let users get their jobs done–a browser that does not allow users to save files would be frustrating to use for most users, and a low-integrity process cannot save files to anywhere useful or convenient. Note the user must initiate the file save operation.

The following code shows how to use some of the new APIs to write data from an application hosted in the browser to a location in the user’s registry that can be written to by low-integrity Internet Explorer.

 HRESULT WriteHKCUSetting(__in_z wchar_t *pwszKey,                          __in_z wchar_t *pwszValue,                          __in_z wchar_t *pwszData) {     BOOL bIsProtected = FALSE;     HRESULT hr = IEIsProtectedModeProcess(&bIsProtected);     if (SUCCEEDED(hr) && bIsProtected) {        HKEY hLowKey = NULL;        hr = IEGetWriteableHKCU(&hLowKey);        if (SUCCEEDED(hr)) {            HKEY hMyKey = NULL;            DWORD dwDisposition = 0;            LONG lRes = RegCreateKeyEx(                 hLowKey,                 pwszKey,                 0L,                 NULL,                 REG_OPTION_NON_VOLATILE,                 KEY_SET_VALUE,                 NULL,                 &hMyKey,                 &dwDisposition);        if (ERROR_SUCCESS == lRes) {           lRes = RegSetValueEx(hMyKey,                                pwszValue,                                NULL,                                REG_SZ,                                (CONST BYTE*)pwszData,                                wcslen(pwszData + 1));           hr = HRESULT_FROM_WIN32(lRes);           RegCloseKey(hMyKey);           } else {              hr = HRESULT_FROM_WIN32(lRes);           }        // Close the low-integrity handle        RegCloseKey(hLowKey);       }     } else {         // IE not in protected mode     }       return hr; } 

And the following code will launch IE in the correct mode for the URL.

 HRESULT LaunchIE(__in_z LPCWSTR pszURL) {    PROCESS_INFORMATION pProcInfo;    HRESULT hr = IELaunchURL(pszURL, &pProcInfo, NULL);    if (SUCCEEDED(hr)) {       CloseHandle(pProcInfo.hProcess);       CloseHandle(pProcInfo.hThread);    }      return hr; }

Important  

Please do not attempt funky tricks to attempt to bypass Protected Mode. Doing so may, in fact, only break your application if Microsoft updates Protected Mode in the future. If you have a specific problem that you don’t seem able to fix, speak to Microsoft.

Debugging Internet Explorer 7 and Protected Mode

The Microsoft Application Compatibility Toolkit 5.0 includes support for debugging many Internet Explorer 7 issues, particularly Protected Mode issues. You can download the tool from Microsoft as part of the Microsoft Application Compatibility Toolkit 5.0 (Microsoft 2006b). At the time we wrote this, you have to download and install the .NET Framework 1.1 too because Windows Vista includes .NET Framework 2.0. Finally, the download Web page will tell you that you need to install Microsoft SQL Server 2005 Express. If all you want to do is run the Internet Explorer toolset, then you don’t need the database engine. Figure 6-1 shows the test tool in action.

image from book
Figure 6-1: Using the Internet Explorer Compatibility Test Tool to analyze Protected Mode failures.

Data Execution Prevention (DEP)

DEP was discussed in detail in Chapter 3, “Buffer Overrun Defenses,” but to save you from flipping back to that chapter, here’s the short version. Almost every buffer that takes advantage of a buffer overrun enters the system as data and then is executed like code. DEP can help stop the code from executing in the first place. Most CPUs today support DEP, as does Windows Vista, and most Windows Vista system processes are DEP-enabled. But there are some processes that may not work correctly when DEP is enabled. Unfortunately, one of those applications is Internet Explorer. The reason DEP is not enabled by default is that Internet Explorer, like all modern graphical browsers, can host other software such as Java applets and various plug-ins and objects, and many of these applications fail when DEP is enabled because they may have self-modifying code or use just-in-time (JIT) compilation.

Note 

Applications that use older versions of the Active Type Library (ATL) also fail to run correctly when DEP is enabled because an ATL-generated function thunks on the fly. You should make sure you update your code to use ATL version 8.0 or higher. You can enforce this by adding this line early in your code: assert(AtlGetVersion(NULL) >= 0x0800);

You can enable DEP in Internet Explorer by performing these steps:

  1. Right-click the Internet Explorer icon.

  2. Select Run as administrator and enter an administrator’s username and password, or click Allow if your account is a member of the Administrator’s group.

  3. Click Tools | Internet Options.

  4. Click the Advanced Tab.

  5. Check Enable memory protection to help mitigate online attacks. If this option is grayed out, you need to launch Internet Explorer as an administrator.

  6. Restart the browser.

Figure 6-2 shows the dialog box.

image from book
Figure 6-2: Enabling DEP in Internet Explorer 7.

At the time of writing, two of the major non-Microsoft tools used in Internet Explorer, Adobe Flash Player v9.0.28.0 and Adobe Acrobat Reader v8.0.0, had just been released, and they both support DEP and run correctly in Internet Explorer when DEP is enabled.

A Short DEP Experiment

Try this little experiment, which assumes your computer is configured to use DEP. Compile and run this code; it’s a variant of some sample code used in Chapter 3.

 // from metasploit unsigned char scode[] =  "\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01\xef\x8b"  "\x4f\x18\x8b\x5f\x20\x01\xeb\x49\x8b\x34\x8b\x01\xee\x31\xc0\x99"  "\xac\x84\xc0\x74\x07\xc1\xca\x0d\x01\xc2\xeb\xf4\x3b\x54\x24\x04"  "\x75\xe5\x8b\x5f\x24\x01\xeb\x66\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb"  "\x8b\x1c\x8b\x01\xeb\x89\x5c\x24\x04\xc3\x31\xc0\x64\x8b\x40\x30"  "\x85\xc0\x78\x0c\x8b\x40\x0c\x8b\x70\x1c\xad\x8b\x68\x08\xeb\x09"  "\x8b\x80\xb0\x00\x00\x00\x8b\x68\x3c\x5f\x31\xf6\x60\x56\x89\xf8"  "\x83\xc0\x7b\x50\x68\x7e\xd8\xe2\x73\x68\x98\xfe\x8a\x0e\x57\xff"  "\xe7\x63\x61\x6c\x63\x2e\x65\x78\x65\x00";   typedef void (*RunShell)( void ); int _tmain(int argc, _TCHAR* argv[]) {      PVOID pBuff = VirtualAlloc(NULL,4096,MEM_COMMIT,PAGE_READWRITE );      if (pBuff) {          memcpy(pBuff,scode,sizeof scode);          // We'll uncomment this code later          // DWORD dwOldProtect = 0;          // VirtualProtect(pBuff,sizeof scode,PAGE_EXECUTE_READ, &dwOldProtect);          RunShell shell = (RunShell)(void*)pBuff;          (*shell)();          VirtualFree(pBuff,0,MEM_RELEASE);      }    return 0; }

When you run it, you’ll see an instance of calc.exe pop-up. As you can probably guess, that’s what the shellcode defined in scode does. There is no buffer overrun in this code; the code is simply calling into a buffer copied onto the heap.

Next, link the code with the /NXCOMPAT linker option. If you’re using Visual Studio 2005, then you need to perform the following steps:

  1. Right-click the project name, and then click Properties.

  2. Expand Configuration Properties.

  3. Expand Linker.

  4. Click Command Line.

  5. In the Additional options text box, type /NXCOMPAT.

  6. Click OK.

Now rerun the code, and you’ll get an access violation on the line that calls the shellcode, (*shell)(). This is DEP working, assuming that your processor supports DEP, and has it enabled in the BIOS.

But let’s say your code has a valid reason to run data even though you have linked with /NXCOMPAT. You can mark the virtual memory as readable and executable by uncommenting the two commented lines of code in the previous sample code. Recompile the code and run it, and you’ll see calc.exe appear. Your application is still protected by DEP, but now your code has a little more flexibility, and can run correctly even with DEP enabled. The call to VirtualProtect marks the virtual memory used to launch calc.exe as readable and executable, so the code runs correctly. Of course, you should use VirtualProtect sparingly and not for all memory allocations (only for those allocations must run code), otherwise DEP will offer little, if any protection.

Important  

At some point in the future DEP will be enabled by default in 32-bit Internet Explorer. It’s enabled by default for 64-bit Internet Explorer today, but you should prepare for the 32-bit eventuality now.



Writing Secure Code for Windows Vista
Writing Secure Code for Windows Vista (Best Practices (Microsoft))
ISBN: 0735623937
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net