In 2002, Microsoft undertook a Trustworthy Computing initiative to make the Windows platform more secure. The company put all new development on hold while developers reviewed their existing code for problems that could lead to security breaches. Many Windows Server 2003 components have benefited from the security initiative. For example, developers made changes at the Windows Management Instrumentation (WMI) COM/Distributed COM (DCOM) level. Most of these changes are fairly minor and affect primarily C++ programmers who use the WMI COM low-level interfaces, but some of these changes affect administrators and WMI scriptwriters. You need to be aware of these three changes:
- Windows 2003 has a lockdown mechanism to secure WMI asynchronous operations.
- Windows 2003 doesn't let you set the Security Descriptor (SD) on a Common Information Model (CIM) repository namespace to Null.
- Windows 2003 removes the Active Directory Service Interfaces (ADSI)WMI extension.
Locking Down Asynchronous Scripts
An asynchronous WMI script has a main routine and a subroutine that's executed in parallel, or asynchronously, to the main routine. The subroutine performs some WMI operations, such as stopping a Windows service or handling an event that occurred during execution of the main routine. The new locking mechanism ensures that the callback of the asynchronous subroutine comes from an authorized entity. For a sample asynchronous script, see the GenericEventAsyncConsumer.wsf script explained in "Exchange 2000 SP2 WMI Updates," January 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 27211.
Generally speaking, when a WMI client application performs an asynchronous operation or event, it first connects to the WMI process, winmgmt.exe. The application handles this connection at the COM level by executing the ConnectServer method, which the WbemScripting.SWbemLocator object exposes. As Arrow 1 in Figure 1 shows, the WMI client passes a pointer to winmgmt.exe during this step so that the WMI process can call the subroutine that the client implements when the action or event occurs (Arrow 2 in Figure 1 shows the subroutine call). The WMI client has some security settings (e.g., impersonation type, authentication level) that winmgmt.exe retrieves when required. The WMI process always attempts to call back the client subroutine with the same authentication level, as Arrow 2 in Figure 1 shows.
However, controlling the security level of the callback is impossible when the WMI client is a WMI script or a Microsoft Management Console (MMC) snap-in, when the client lacks the functionality to control the security settings of the process, or in pre-Windows 2000 environments (because the machine Local System account doesn't have a network identity in these environments). In such cases, when the WMI client invokes an asynchronous operation, the underlying WMI COM mechanisms start the unsecapp.exe application in a separate process on the client, as Arrow 1 in Figure 2 shows. This behavior is the same for all Windows versions.
Unsecapp.exe passes its own pointer to the client. The underlying WMI COM mechanisms then pass unsecapp.exe along with the WMI script's asynchronous operation call to winmgmnt.exe, as Arrow 2 in Figure 2 shows. The winmgmt.exe callback uses unsecapp.exe, as Arrow 3 in Figure 2 shows. Because the WMI script can't enforce callback security as a COM/DCOM WMI client can, unsecapp.exe accepts callbacks from anyone. Unsecapp.exe obviously presents a security risk because any process can perform the callback on behalf of winmgmt.exe. After accepting the callback, unsecapp.exe returns the callback to the WMI script at the subroutine level executed asynchronously, as Arrow 4 in Figure 2 shows. Note that unsecapp.exe is involved only during asynchronous operations. Synchronous and semisynchronous operations don't use the same mechanism. For more information about the differences, see "Making an Asynchronous Call with VBScript" and "Making a Semisynchronous Call with VBScript".
Locking down scripts in Windows XP, Win2K, and Windows NT 4.0. Microsoft has implemented a lockdown mechanism for unsecapp.exe in Windows 2003, but at the time of this writing, the company has no plan to implement a similar mechanism for earlier Windows versions. Thus, when you consider using asynchronous operations or event notifications in WMI scripts in XP, Win2K, and NT 4.0, you should take the following precautions:
- If possible, use a synchronous or semisynchronous scripting technique instead of an asynchronous one.
- If you absolutely must use an asynchronous scripting technique, make sure that the script doesn't use a powerful security context (e.g., an administrative security context) to perform a crucial operation (e.g., a system shutdown) in the subroutine that handles the asynchronous callback. You should restrict any type of script from being executed in the security context of an administrator whenever possible, but be extra careful with asynchronous scripts. If you implement an asynchronous scripting technique, you should implement access checks in the client code.