Advisory on July 2018 .NET Framework Updates

[richlander]

Advisory on July 2018 .NET Framework Updates

Updated: 08/14/2018

A new .NET Framework August 2018 Update has been released that resolves this advisory for all supported Windows versions.

A new .NET Framework July 2018 Update has been released that resolves this advisory. See Guidance section.

Guidance has changed for Windows 7, Windows Server 2008 and Windows Server 2008 R2. See Guidance section.

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.

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 issue and post as we have new information.

Guidance

We strongly recommend that you install .NET Framework August 2018 Update.

We recommend that you install .NET Framework July 2018 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, in August.

On Windows 7, Windows Server 2008, and Windows Server 2008 R2, we have found that the combination of July 2018 Security and Quality Rollup updates for .NET Framework and .NET Framework July 2018 Update do not resolve all symptoms. On these Windows versions, if you are experiencing these symptoms after installing this combination of patches, we recommend that you uninstall (only) the Monthly Rollup patch and then install the appropriate Security Only patch listed at July 2018 Security and Quality Rollup updates for .NET Framework.

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.

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

[Dijkgraaf]

So the two workarounds for BizTalk (Uninstall the patch, or the NETWORK SERVICE one) both are described as "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."

So what is recommended for BizTalk?

[richlander]

@Dijkgraaf You are right. We are actively investigating this issue and don't have a better option to offer. We completely understand if the workaround we gave isn't acceptable to you.

[ag-work]

Hello. I have server with OS windows server 2012 r2 and iis version 8.5.9600.16384.
And I have web application on asp.net mvc target framework = 4.6.2.
Application Pools: .Net CLR Version = v4.0, Managed Pipeline Mode = Integrated, Identity = ApplicationPoolIdentity.
Permissions on project folder for IUSR and IIS_IUSRS = Full control.

After update system I got error:
System.TypeInitializationException: The type initializer for 'EmitMapper.DynamicAssemblyManager' threw an exception. System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(RuntimeAssembly containingAssembly, Boolean emitSymbolInfo, String name, String filename, StackCrawlMarkHandle stackMark, IntPtr& pInternalSymWriter, ObjectHandleOnStack retModule, Boolean fIsTransient, Int32& tkFile) at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(RuntimeAssembly containingAssembly, Boolean emitSymbolInfo, String name, String filename, StackCrawlMark& stackMark, IntPtr& pInternalSymWriter, Boolean fIsTransient, Int32& tkFile) at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModuleInternalNoLock(String name, String fileName, Boolean emitSymbolInfo, StackCrawlMark& stackMark) at System.Reflection.Emit.AssemblyBuilder.DefineDynamicModuleInternal(String name, String fileName, Boolean emitSymbolInfo, StackCrawlMark& stackMark)

When I uninstalled KB4338419, website start work fine.
How I can fix it?
This is correct topic or better write on other place?

[lisas-dev]

I thought I would add the error message I'm receiving related to this issue, since I have not found this exact error message mentioned anywhere and thought it might help someone else searching on this error. This error occurred in classic asp calling a .NET interop COM object:
Server object error 'ASP 0178 : 80070005'
Server.CreateObject Access Error
The call to Server.CreateObject failed while checking permissions. Access is denied to this object.

[richlander]

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.

[StephenY-Titian]

@richlander This update fixes the problem for us on 2012 R2, but not on 2008 R2. On 2008 R2 the KB4338420 update installed mscoreei.dll 4.7.3130.0 which includes the problematic "OpenProcessToken()" call, and the KB4346407 update doesn't touch mscoreei.dll, so we still have the problem.

Updated 1st Aug: Note that the problems on 2008 R2 are when we install the new update over the top of the original update.

[lisas-dev]

This update did not resolve the issue on Windows 7 either.

[ag-work]

This update solved my problem on production server, but local windows 10 I can't install update windows10.0-kb4346877-x64.

Windows Update Standalone Installer
The update is not applicable to your computer.

[richlander]

Thanks for these reports. Please keep them coming.

We are actively investigating.

[richlander]

Thanks for the report @StephenY-Titian. What scenario was broken that led you to discover that mscoreei.dll still contained the bad OpenProcessToken call?

To @StephenY-Titian and anyone else, feel free to email me directly at rlander@microsoft.com

[StephenY-Titian]

@richlander Our scenario is with Classic ASP web pages with Windows Integrated Authentication. I've emailed you more details.

[richlander]

Thanks for sending that. The information your shared was super useful.

[richlander]

Guidance has changed for Windows 7, Windows Server 2008 and Windows Server 2008 R2. See Guidance section.

[StephenY-Titian]

Thanks @richlander and team - the updated guidance solves the problem in our scenario on Server 2008 R2.

[mroset]

Hi, I wanted to share the following with you:

I am also facing an issue in a Windows Server 2008 R2 SP1 environment. (Classic ASP / Integrated Windows Authentication / COM-components) as a result of installing the defective .NET July 2018 updates, and finding that the July 30th 2018 fixes do not resolve the issue (like it did in another Windows Server 2012 environment - see Additional Comment below).
I've tried the new Guidance section instructions for W2K8R2 environments as well to no avail (which seem to have worked for @StephenY-Titian but not for me yet…).

Then, I simply decided to roll back ALL the Windows Updates that had been installed since the moment that everything was still working fine, hoping that at least we would be back to the situation where everything in IIS/ASP still worked.
Surprise: That did not resolve the issue either.

So, that brought us into a bit of a 'no way forward, no way back' situation here.
The workaround does work (invoking the .NET/COM components with an administrator account, after which it works for all other (non-administrator) users as well until the machine is restarted OR the Application Pool in IIS is restarted.)

Additional comment:
Please note that on Friday 3rd of august, applying the fixes to a completely different customer environment (Windows Server 2012 based) the fixes worked brilliantly and fixed the IIS/ASP issues. So the remaining issues are concentrated to Windows Server 2008 (in our case R2) environments only.

Situation for now:

• We're forced to use the workaround so that the Intranet IIS-based application works properly for non-administrator users
• We'll have to wait until the August 2018 .NET fixes that will (hopefully) resolve these major issues structurally.

I'll keep monitoring this thread and will update you when I find something new on my end.
For now, I do have to say that this has cost a valuable 3 days (and counting) to troubleshoot and resolve for customers. As a software developer, I realize that software is very complex, but these July 2018 .NET updates have truly been desastrous for many, many more facing similar problems…. Definitely a nightmarish period for Microsoft....

[mroset]

Hi Rich, please note that if this specific environment can be interesting 'test material' for Microsoft in getting to the bottom of this issue in W2K8 R2, please let me know. I realize that one always first has to be able to reproduce the issue, before one can analyze and eventually resolve it.

I would be happy to analyze this further and try new fixes as they come available. Hopefully the future solution will benefit others that are facing similar problems.

[richlander]

I am sorry to here that @mroset ... please feel free to email me directly @ rlander@microsoft.com

[mroset]

Hi Rich,

With your and Tara's excellent help (thanks !) the Guidance Section proved successfull for us as well. See below followed steps for anyone facing similar issues.

===================

I took the following actions, initially only on the TEST server (W2K8 R2 SP1 x64):

1. Uninstalled KB4338423 (.NET 3.5.1)
2. Could not uninstall KB4338417 (Not available in the list of updates / most probably not applicable to this system)
3. Uninstalled KB4338420 (.NET 4.7.2)
4. Restarted server
5. Installed KB4338612 (.NET 3.5.1.)
6. Could not install KB4338602 (“…does not apply, or is blocked by another condition on your computer.” / most probably not applicable to this system)
7. Installed KB4338606 (.NET 4.7.2)
8. Restarted server

FINDINGS / RESULT:
*** Problem solved ***

9. Repeated steps 1-8 on the PROD server (same environment), and obtained the same result.
10. Checked Windows Update (KB4340556 has NOT been installed, because this would reintroduce the problem, see https://support.microsoft.com/en-us/help/4340556/security-and-quality-rollup-updates-for-net-framework-3-5-1-4-5-2-4-6 )

(Note: Make sure NOT to install KB4340556 from Windows Update, since that would reintroduce the problem. Instead, wait for the structural solutions from Microsoft in the next Roll Up update)

[richlander]

A new .NET Framework August 2018 Update has been released that resolves this advisory for all supported Windows versions.