Advisory on July 2018 .NET Framework Updates

Update as of 7/30/2018:

A new .NET Framework July 2018 Update has been released that resolves this advisory. We recommend that you install this update on your systems if you experienced the symptoms described in this advisory. If you did not experience these symptoms, we recommend you wait to update your machines until the next regular update.

The July 2018 Security and Quality Rollup updates for .NET Framework was released earlier this month. We have received multiple customer reports of applications that fail to start or don’t run correctly after installing the July 2018 update. These reports are specific to applications that initialize a COM component and run with restricted permissions. You can reach out to Microsoft Support to get help.

We have stopped distributing the .NET Framework July 2018 updates on Windows Update and are actively working on fixing and re-shipping this month’s updates. If you installed the July 2018 update and have not yet seen any negative behavior, we recommend that you leave your systems as-is but closely monitor them and ensure that you apply upcoming .NET Framework updates.

As a team, we regret that this release was shipped with this flaw. This release was tested using our regular and extensive testing process. We discovered while investigating this issue that we have a test hole for the specific combination of COM activation and restricted permissions, including impersonation. We will be mitigating that gap going forward. Again, we are sorry for any inconvenience that this product flaw has caused.

We will continue to update this post and dotnet/announcement #74 as we have new information.

Technical Context

The .NET Framework runtime uses the process token to determine whether the process is being run within an elevated context. These system calls can fail if the required process inspection permissions are not present. This causes an “access denied” error.

Workaround

Temporarily uninstall the July 2018 Security and Quality Rollup updates for .NET Framework to restore functionality until a new update has been released to correct this problem.

Symptoms

A COM component fails to load because of “access denied,” “class not registered,” or “internal failure occurred for unknown reasons” errors.

The most commonly reported failure results in the following error message:

Exception type: System.UnauthorizedAccessException
Message: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Sharepoint

When users browse to a SharePoint site they may see the following HTTP 403 message:

"The Web Site declined to show this webpage"

The SharePoint ULS Logs will contain a message like the following:

w3wp.exe (0x1894)         0x0B94  SharePoint Foundation  General 0000       High                UnauthorizedAccessException for the request. 403 Forbidden will be returned. Error=An error occurred creating the configuration section handler for system.serviceModel/extensions: Could not load file or assembly <AssemblySignature>  or one of its dependencies. Access is denied. (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Config\machine.config line 180)    

w3wp.exe (0x1894)         0x0B94  SharePoint Foundation  General b6p2      VerboseEx                Sending HTTP response 403:403 FORBIDDEN.      

w3wp.exe (0x1894)         0x0B94  SharePoint Foundation  General 8nca       Verbose                Application error when access /, Error=Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

When crawling a people content source, the request may fail with the following entry logged to the SharePoint ULS Log:

mssearch.exe (0x118C) 0x203C SharePoint Server Search Crawler:Gatherer Plugin cd11 Warning The start address sps3s://<URLtoSite> cannot be crawled.  Context: Application 'Search_Service_Application', Catalog 'Portal_Content'  Details:  Class not registered   (0x80040154)  

IIS Hosted Classic ASP calling CreateObject for .NET COM objects may receive error "ActiveX component can't create object" 

.NET Application creates instance of .NET COM application within an Impersonation Context may receive error "0x80040154 (REGDB_E_CLASSNOTREG)"

BizTalk Server Administration Console

BizTalk Server Administration Console fails to launch properly with the following errors:

An internal failure occurred for unknown reasons. (WinMgmt) 

Program Location:  

   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) 

   at System.Management.ManagementObject.Get() 

   at Microsoft.BizTalk.SnapIn.Framework.WmiProvider.SelectInstance

Warning: The following workarounds may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend these workarounds but are providing this information so that you can implement the workarounds at your own discretion. Use these workarounds at your own risk.

Use the following guidance as a workaround:

Add “NETWORK SERVICE” to the local Administrators group.

IIS with Classic ASP

IIS Hosted Classic ASP calling CreateObject for .NET COM objects may receive the following error: “ActiveX component can’t create object”. Use the following guidance as a workaround.

If your web site uses Anonymous Authentication, change the Web Site Anonymous Authentication credentials to use the “Application pool identity”
If your site uses Basic Authentication, log into the application once as the application pool identity and then create an instance of the .NET COM component. All subsequent activations for that .NET COM component should succeed, for any user.

.NET applications using COM and impersonation

.NET Applications that creates instances of .NET COM application within an Impersonation Context may receive the following error: “0x80040154 (REGDB_E_CLASSNOTREG)”. Use the following guidance as a workaround.

Create an instance of the .NET COM component prior to the impersonation context call. Later impersonated create instance calls should work as expected.
Run the .NET Application in the context of the impersonated user
Avoid using Impersonation when creating the .NET COM object