AppInit DLLs in Windows 7 and Windows Server 2008 R2 - 2
AppInit DLLs in Windows 7 and Windows Server 2008 R2
May 15, 2009
Abstract
This paper provides information about the AppInit_DLLs infrastructure for the Windows® family of operating systems. It provides guidelines for application developers to ensure that any applications that depend on the AppInit_DLLs mechanism function correctly when run in Windows7 or Windows Server® 2008R2.
The AppInit_DLLs infrastructure enables applications to load arbitrary DLLs into all user-mode processes. The most common use of this mechanism is API hooking. The AppInit_DLLs infrastructure has been changed for Windows7 and Windows Server 2008 R2 to help improve the integrity and visibility of code that is running on these systems. This paper includes information about the new code signature requirement that has been introduced for AppInit_DLLs. It also includes information that is related to the following message that is observed in Event Viewer:
Custom dynamic link libraries are being loaded for every application. The system administrator should review the list of libraries to ensure they are related to trusted applications.
This information applies to the following operating systems:
Windows 7
Windows Server 2008 R2
References and resources discussed here are listed at the end of this paper.
The current version of this paper is maintained on the Web at:
http://www.microsoft.com/whdc/driver/install/AppInit-Win7.mspx
Disclaimer: This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.
© 2009 Microsoft Corporation. All rights reserved.
Microsoft, Authenticode, Visual Studio, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Document History
Date / Change /May 15, 2009 / Added note in Abstract about Event Viewer message
April 22, 2009 / First publication
Contents
Introduction 4
AppInit_DLL Functionality in Windows 7 and WindowsServer2008R2 4
Configuration 4
DRM-Protected Processes 5
Windows 7 Upgrades 5
Windows 7 5
Windows Server 2008 R2 5
Blocked Process List 5
System Event Log Entry 6
Developer Best Practices 6
Code Signature Overview 6
Detailed Code Signature Information 9
Getting Started with Code Signing 9
Overview of the Code-Signing Tools 9
Where to Find the Code-Signing Tools 11
How to Run the Code-Signing Tools 12
How to Prepare the Signing Computer 12
How to Test-Sign a DLL Binary File 13
Step 1: Create a Test Certificate by Using MakeCert 13
Step 2: Install the Test Certificate in the Trusted Root Certification Authorities Certificate Store 16
Step 3: Test-Sign a DLL Binary File with an Embedded Signature 17
Step 4: Verify the Test Signature 17
How to Install and Verify a Test-Signed DLL 18
Step 1: Install the Test Certificates on the Test System 18
Step 2: Enable the Test-Signing Boot Configuration Option 20
Step 3: Enable Code Integrity Event Logging and System Auditing 21
Step 4: Copy and Install the Test-Signed DLL to the Test Computer 22
Step 5: Verify that the Test-Signed DLL Is Operating Correctly 22
How to Release-Sign a DLL Binary File 22
Step 1: Obtain and Install an SPC 23
Step 2: Obtain and Install a Cross-Certificate 25
Step 3: Release-Sign a DLL File with an Embedded Signature 26
How to Install and Verify a Release-Signed DLL 28
Step 1: Disable the Test-Signing Boot Configuration Option 29
Step 2: Enable Code Integrity Event Logging and System Auditing 29
Step 3: Restart the Test Computer 29
Step 4: Copy and Install the Release-Signed AppInit DLL to the Test Computer 29
Step 5: Verify that the Release-Signed AppInit DLL Is Operating Correctly 29
Feedback 29
Resources 30
Introduction
One of the key reasons for the success of the Windows® platform is its inherent extensibility. Not only does the Windows operating system provide a platform for developing and executing a variety of applications and scenarios, Windows also provides infrastructures that allow applications to extend the core functionality of the operating system. One example of this extensibility is an infrastructure known as AppInit_DLLs.
The AppInit_DLLs infrastructure provides a mechanism that lets an arbitrary list of DLLs (AppInit DLLs) be loaded into each user-mode process on the system. Today, only a small set of legitimate applications use this mechanism. Unfortunately, a larger set of malware use this mechanism. Applications and malicious software both use AppInit DLLs for the same basic reason, which is to hook APIs.
The AppInit_DLLs infrastructure provides an easy way to hook system APIs by allowing a custom DLL to be loaded into the address space of every interactive application. After the custom DLL is loaded, it can hook a well-known system API and implement alternate functionality.
Using AppInit DLLs can unintentionally cause system deadlocks and performance problems, because they are loaded during the initialization of user32.dll. We do not recommend that you load a DLL during the initialization of another DLL. For more information about problems that can occur when you use AppInit DLLs, see ”AppInit_DLLs should be renamed Deadlock_Or_Crash_Randomly_DLLs” in one of the blogs on the MSDN® Web site.
To help improve system reliability, performance, and visibility into the origin of software, the AppInit_DLLs mechanism has been updated for Windows 7 and Windows Server® 2008 R2 to include a new code-signing requirement.
This paper describes the new code-signing requirement and provides best practices for developers to follow when they use AppInit DLLs.
AppInit_DLL Functionality in Windows 7 and WindowsServer2008R2
Beginning with Windows Vista®, the AppInit_DLLs infrastructure is disabled by default. This default behavior remains unchanged in Windows 7 and Windows Server2008 R2.
Configuration
The behavior of the AppInit_DLLs infrastructure is configured by a set of values that are stored under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT \CurrentVersion\Windows key in the registry. These registry values are described in Table1.
Table 1. AppInit_DLLs Infrastructure Registry Values
Value / Description / Sample values /LoadAppInit_DLLs
(REG_DWORD) / Value that globally enables or disables AppInit_DLLs. / 0x0 – AppInit_DLLs are disabled.
0x1 – AppInit_DLLs are enabled.
AppInit_DLLs
(REG_SZ) / Space -or comma-delimited list of DLLs to load. The complete path to the DLL should be specified by using short file names. / C:\PROGRA~1\Test\Test.dll
RequireSignedAppInit_DLLs
(REG_DWORD) / Require code-signed DLLs. / 0x0 – Load any DLLs.
0x1 – Load only code-signed DLLs.
DRM-Protected Processes
AppInit DLLs are not loaded into any DRM-protected process. This behavior cannot be configured. For more information about protected processes, see “Protected Processes in Windows Vista” on the WHDC Web site.
Windows 7 Upgrades
When you upgrade a Windows Vista system to Windows7, the AppInit DLLs that are listed in the registry do not migrate to the Windows 7 registry. Also, when you upgrade from an earlier version of Windows to Windows7, the AppInit DLL image files are not copied into the new Windows7 operating system directories.
Windows 7
We recommend that you code-sign all DLLs that the AppInit_DLLs infrastructure loads into Windows 7. But for application compatibility, by default Windows7 loads all AppInit DLLs, regardless of whether these DLLs are code signed. Nevertheless, we recommend that you digitally code-sign your AppInit DLLs to help improve the reliability and security of Windows7 and to prepare for more stringent code-signing requirements in future versions of Windows.
The RequireSignedAppInit_DLLs registry value controls whether AppInit DLLs must be code signed. In Windows 7, this value is set to 0 (load any DLLs) by default.
Windows Server 2008 R2
By default, all DLLs that Windows Server2008R2 loads by using the AppInit_DLLs infrastructure must be code signed. In Windows Server 2008 R2, the RequireSignedAppInit_DLLs registry value is set to 1 (load only code-signed DLLs) by default.
Blocked Process List
AppInit DLLs are not loaded into the following security critical processes:
· Windows Defender.
· Windows Software Licensing service.
· Microsoft Hyper-V critical processes (vmms.exe and vmwp.exe).
You cannot configure this behavior.
System Event Log Entry
If an application enables AppInit DLLs, Windows logs a warning in the System Event Log. The event log entry includes a list of the DLLs that are loaded by using the AppInit_DLL mechanism. You can view this list on the Details tab in Event Viewer. Wininit logs this warning one time for each boot session. Table 2 shows the fields of the event log entry when you view the entry in Event Viewer.
Table 2. System Event Log Entry Fields in Event Viewer
Provider / Level / Event ID / Channel / Message /Wininit / Warning / 11 / System / Custom dynamic link libraries are being loaded for every application. The system administrator should review the list of libraries to ensure that they relate to trusted applications.
Developer Best Practices
The following are best practices for software developers who create AppInit DLLs:
· Code-sign AppInit DLLs.
Software developers should code-sign any AppInit DLLs to help improve the reliability and security of Windows7. Later versions of Windows will load only code-signed AppInit DLLs and will not include a registry key to disable this requirement.
· Run DLLs only in required processes.
The AppInit_DLLs mechanism loads the specified DLLs in all user-mode processes on the system. If an AppInit DLL must provide API hooks only to specific processes, then the DLL should call the GetModuleFileName function from within DllMain to retrieve the name of the process in which it is loaded. If the process is not a process that requires the API hooking that the AppInit DLL provides, then the DLL should simply return from DllMain.
· Only call APIs that are exported from kernel32.dll in the DLL's initialization routine.
Because AppInit DLLs are loaded very early during process initialization, they should use only APIs that are exported from kernel32.dll in their initialization routines.
Code Signature Overview
Code signing uses digital signatures to verify the integrity of software applications and components. A valid digital signature identifies the software's publisher and verifies that the software has not been modified since it was signed.
A digital signature assures users that the software that they are installing or running is genuine. Software that is code signed cannot be anonymous. By providing the identity of the publisher of AppInit DLLs in the digital signature, end-users and IT professionals can communicate with the software vendor if their AppInit DLL causes system performance or reliability issues.
Note: Code signing does not provide any guarantee of the quality or functionality of software. Code-signed software can still contain flaws or security vulnerabilities or can be malicious in nature.
In Windows 7 and Windows Server 2008 R2, if the AppInit_DLLs infrastructure is enabled and the RequireSignedAppInit_DLLs registry value is set to 1, then only code-signed AppInit DLLs are loaded. In this situation, if a DLL in the AppInit_DLLs registry value has not been code signed or has a problem with its digital signature, the operating system does not load the DLL.
The digital signature of a DLL is usually embedded in the binary file (the .dll file). When the digital signature is embedded in the binary file, Windows 7 and Windows Server 2008 R2 verify the signature only the first time that the DLL is loaded. The digital signature is cached after the DLL is loaded the first time. If the DLL is subsequently reloaded into the same process, the operating system does not verify the digital signature again.
To code-sign a DLL and embed the digital signature in the binary file, the following steps are required:
1. Link the DLL with the /integritycheck linker option. The /integritycheck option is supported by both Microsoft® Visual Studio® 2005 and Visual Studio 2008, including the free Express Editions.
To verify that the /integritycheck linker option was specified when a DLL was linked, run the following command in a command prompt window:
dumpbin /headers DLLname.dll
If the /integritycheck linker option was specified when the DLL was linked, Check integrity is included in the list of DLL characteristics in the output from the dumpbin utility, as shown in the following example:
c:\>dumpbin /headers test.dll
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
14C machine (x86)
3 number of sections
48F57FF2 time date stamp Tue Oct 14 22:30:26 2008
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2122 characteristics
Executable
Application can handle large (>2GB) addresses
32 bit word machine
DLL
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version