MS09-012: Description of the security update for Windows Service Isolation: April 2009

Known issues with this security update

• Symptoms
  
  After you apply this update on a server that uses more than four CPU cores and that is running Microsoft ISA Server Standard Edition, the Microsoft ISA Server Control service does not start. Additionally, Event ID 14109 is logged in the Application log.
  
  Cause
  
  This problem may occur if a hotfix that was released after February 7, 2007 is installed before the security update is installed. This problem occurs because of a change to the way that Windows reports the number of CPUs that are available. This change was first introduced in hotfix 932730. The change causes Windows Server 2003 to report this information exactly as Windows Vista and Windows Server 2008 reports the information. When Windows reports more than four CPU cores, the ISA Server Control service interprets this to mean more than four CPUs. This triggers an alert and then shuts down the Microsoft ISA Server Control service and any dependent services.
  
  Note Hotfix 932730 was not included with any Windows Server 2003 service pack.
  
  For more information about hotfix 932730, click the following article number to view the article in the Microsoft Knowledge Base:
  
  
  932370 The number of physical hyperthreading-enabled processors or the number of physical multicore processors is incorrectly reported in Windows Server 2003
  
  
  For more information about how to work around this issue, visit the following Microsoft Web page:
  
  
  http://blogs.technet.com/isablog/archive/2009/04/18/ms09-012-and-isa-server-standard-edition-14109-failures.aspx
  To resolve this issue for ISA Server 2004, install hotfix rollup 970454. For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:
  
  970454 Description of the ISA Server 2004 hotfix package: June 2, 2009
  
  To resolve this issue for ISA Server 2006, install hotfix rollup 970441.
  
  For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:
  
  970441 FIX: The ISA Server Control service cannot start after you install the MS09-012 update on a computer that is running Windows Server 2003 and that has more than 4 CPU cores
  
  
  Note No patch was issued for ISA Server 2000 because ISA Server 2000 is no longer in mainstream support, and this issue does not constitute a security vulnerability.
  
  
• After you apply this update, and then an in-place upgrade is performed from an earlier released operating system to a new operating system, user-applied changes may not be preserved on the following registry subkeys:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  This problem may occur in the following upgrade scenarios:
  
  
  
  • Windows XP to Windows Vista
  • Windows Server 2003 to Windows Server 2008
  • Windows 2000 Server to Windows Server 2003
  
  
  
  This problem does not occur in the following upgrade scenarios:
  
  
  • Windows Vista to Windows 7
  • Windows Server 2008 to newer service packs or to future server-based operating systems.
  To avoid this problem, create a backup of these subkeys before you perform the in-place upgrade. Reapply the subkey backups after the upgrade is complete and after the system is patched with security updates.

FAQ for independent software vendors (ISV) (COM)

1. Does your product have to start a non-NT service COM server process?
2. By default, does the COM server that your product instantiates run in the context of Network Service or Local Service Account?
   

1. Download and install Process Explorer from the following Microsoft Web site:
   http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
2. Run Process Explorer as a local administrator.
3. Click View, point to Lower Pane View, and then click Handles.
4. Click the server process of interest, and then look in the lower pane for Type = Token.
5. Run all the test suites for your product.
6. Look at the lower pane for all the tokens that are owned to see whether a system token is captured.

1. Download and install Debugging Tools for Windows from the following Microsoft Web site:
   http://www.microsoft.com/whdc/devtools/debugging/default.mspx
2. Run WinDBG.exe as a local administrator.
3. Click File, and then click Kernel Debug to start local kernel debugger.
4. Click File, and then click Attach to a Process.
5. Click the server process of interest, and then click
   OK to attach to the server process.
6. Set the debugger symbol path as follows. Substitute your downstream store path for DownstreamStore. For example, C:\Symbols.
   
   SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
7. Dump the process token information.
   Get the token address from the output of !process, then use the dt nt!_TOKEN command to display a list of the individual fields of the TOKEN structure.
8. Look at the ImpersonationLevel field of the token.

• Install the MSRC package.
  
• Make the following configuration change for your COM server:
  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID} REG_DWORD AppIDFlags 0x2 /* Example of the usage of AppIDFlags registry value HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{60EE1F45-C0DD-4A1F-AA44-D97424600A16} REG_DWORD AppIDFlags 0x2 */
  Note Local Administrator credentials are required to make the change.
  
  If an NS/LS COM server that contains privileged tokens is not an NT service or is not a RunAs COM server, it must be converted into one of these configurations to prevent the vulnerability.

• The installer should determine whether the following registry key exists:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572
  If this registry entry exists, security update 956572 is present on the system.

FAQ for system administrators (COM)

1. Does your product have to start a non-NT service COM server process?
2. By default, does the COM server that your product starts run in the context of Network Service or Local Service Account?
   

FAQ for ISV (Services.exe)

1. Does your product install services that are started by using the SCM framework?
2. By default, do the services that your product installs run in the context of Network Service or Local Service Account?
   
3. If your service runs on Windows Vista or on Windows Server 2008, run the following command from an elevated command prompt:
   SC.EXE QSIDTYPE <ServiceName>
   Is the SERVICE_SID_TYPE value NONE?
   
   Output:

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: NONE 

   If the answer to each of these three questions is yes, your service may potentially be vulnerable. To continue with the investigation to identify if your service is vulnerable, follow the Process Explorer-related steps in Answer 1 of the "FAQ for independent software vendors (ISV) (COM)" section.

• Install the MSRC package.
  
• Run the following command from an elevated command prompt:
  SC.exe SIDTYPE <ServiceName> UNRESTRICTED
• Restart the service from the services control manager.
• Validate that your service has obtained a Service SID by running the following command:
  SC.exe QSIDTYPE <Service Name>
  Output:
  

  [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: UNRESTRICTED 

• If you see SERVICE_SID_TYPE = UNRESTRICTED, your service has obtained a SID.
• Run all test cases to make sure that no functionality that is provided by your service is broken.
• The following sequence of commands will help remove the Service SID on the service:
  SC.exe SIDTYPE <ServiceName> NONE
  SC.exe STOP <ServiceName>
  SC.exe START <ServiceName>

1. Change the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>\ServiceSidType = 1
2. After this the update, the installer should restart the system.

• The installer should determine whether the following registry key exists:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572
  If this registry entry exists, security update 956572 is present on the system.

FAQ for System Administrators (Services.exe)

1. Does your product install services that are started by using the SCM framework?
2. By default, do the services that your product installs run in the context of Network Service or Local Service Account?
   
   Note If your service runs on Windows Vista or on Windows Server 2008, run the following command from an elevated command prompt to determine the context:
   SC.exe QSIDTYPE <Service Name>
   Output:
   

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Service Name> SERVICE_SID_TYPE: UNRESTRICTED 

   If the answer to each of these three questions is yes, these services could potentially be vulnerable. To help secure these services, contact the ISV who owns the service. If the service was developed in-house, follow the steps in Answer 1 of the "FAQ for independent software vendors (ISV) (COM)" section.

FAQ for independent software vendors (ISV) (WMI)

1. Open the ".mof" files for the WMI Providers and verify whether any of the providers has one of the following hosting models:
   
   • NetworkServiceHost
   • NetworkServiceHostToSelfHost
   • LocalServiceHost
   • NULL (only in the case of Windows Vista or Windows Server 2008)
2. As part of the token kidnapping package, only WMI Providers shipped inbox are secured by default. If your provider is an inbox provider, it should ideally be secured after installed the token kidnapping package. To verify this, please check the registry values under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders subkey. If a provider is secured, you should see an entry similar to the following:

   <NameSpace>:_Win32Provider.Name ="<Provider Name>" REG_SZ 0. 

3. If your provider is listed here, then that particular provider would be launched in secure mode.
4. If the provider name is not listed under the SecureHostProviders registry key, and the hosting model is one of the models that are listed in step 1, then this provider will be launched in an unsecured Wmiprvse.exe and will make the computer vulnerable to the token kidnapping attack.

1. Log on to a computer that has your product installed as an Administrator.
2. Download and install Process Explorer from the following Microsoft Web site:
   
   http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
3. Run Process Explorer as a local administrator.
4. Click View, point to Lower Pane View, and then click Handles.
5. Use Task Manager to identify and close all the Wmiprvse.exe processes that are running under the context of Network Service or Local Service.
6. Execute a test case for your application that exercises a WMI query using a specific WMI provider. This will create a new WMIPrvSE.exe process to service the new WMI query that you just executed.
7. On the Process Explorer toolbar, make sure that you have selected View DLLs.
8. Look in the lower pane to see whether your DLL has been loaded in the newly created WMIPrvSE.exe.
9. Double-click WMIPrvSE.exe to open the
   Properties dialog box.
10. Click the Security tab and make sure that the following is correct:
    
    • The logon SID is of the form (S-1-5-5-****).
    • The logon SID is also marked as the owner.
    • WMI SID for ServiceAcccount {Local Service|Network Service} will be marked as owner.
      
      • WMI SID for Local Service:
        
        S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952
      • WMI SID for Network Service:
        
        S-1-5-86-615999462-62705297-2911207457-59056572-3668589837
11. Click Permission, and verify that neither Network Service nor Local Service come up in the list. This will confirm that your provider is now being launched in secured mode.

• HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  
  
  All providers listed under this key will always run in secured mode.
• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  If a provider is listed under this key, it will run in unsecured mode. This key is provided so that an ISV can add an exception for a particular provider that has compatibility issues running in safe mode. By default it will contain 0 (zero) entries.
• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  
  If this global registry key is set to 1, it will launch all the WMI Providers on the computer in secured mode regardless of they are listed or not listed in any of the registry keys above. Microsoft has not set this to 1 by default because we have not tested the behavior of all possible third-party applications with this registry key set to 1.

<NameSpace>:_Win32Provider.Name =”<Provider Name>” REG_SZ 0. 

FAQ for System Administrator (WMI)

1. Log on to a computer which has your product installed as an Administrator.
2. Download and install Process Explorer from the following Microsoft Web site:
   
   http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
3. Run Process Explorer as a local administrator.
4. Click View, point to Lower Pane View, and then click Handles.
5. Using Task Manager, identify and close all the Wmiprvse.exe processes that are running under the context of Network Service or Local Service.
6. Execute a test case for your application that exercises a WMI query using a specific WMI Provider. This will create a new WMIPrvSE.exe process to service the new WMI query that you just executed.
7. On the Process Explorer toolbar, make sure that you have selected View DLLs.
8. Look in the lower pane to see whether your DLL has been loaded in the newly created WMIPrvSE.exe.
9. Double-click WMIPrvSE.exe to open the
   Properties dialog box.
10. Click the Security tab, and then make sure that the following is correct:
    
    1. "Network Service" or "Local Service" has full permissions on the Wmiprvse.exe process.
    2. Make sure that the logon SID (of the form S-1-5-5-**** ) is not marked as owner.
    3. Make sure that the WMI SID for ServiceAcccount {Local Service|Network Service} is not generated. That is, make sure that it is not visible under "Group."
       • WMI SID for Local Service: S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952
       • WMI SID for Network Service: S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

1. Open Registry Editor.
2. Go to the following registry subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
3. Add an registry value for the WMI provider to be secured. Use the following format:

   <NameSpace>:_Win32Provider.Name =”<Provider Name>” REG_SZ 0 

4. Restart the WMI service by running the following commands.
   
   • Sc stop winmgmt
   • Sc start winmgmt