Related topics
×
Sign in with Microsoft
Sign in or create an account.
Hello,
Select a different account.
You have multiple accounts
Choose the account you want to sign in with.

Release Date:
October 13, 2020

Version:
.NET Framework 4.8

Summary

Security improvements

An information disclosure vulnerability exists when the .NET Framework improperly handles objects in memory. An attacker who successfully exploited the vulnerability could disclose contents of an affected system's memory. To exploit the vulnerability, an authenticated attacker would need to run a specially crafted application. The update addresses the vulnerability by correcting how the .NET Framework handles objects in memory.

To learn more about the vulnerabilities, go to the following Common Vulnerabilities and Exposures (CVE).

Quality and reliability improvements

WCF1

- Addressed an issue with WCF services sometimes failing to start when starting multiple services concurrently.

Winforms

- Addressed a regression introduced in .NET Framework 4.8, where Control.AccessibleName, Control.AccessibleRole, and Control.AccessibleDescription properties stopped working for the following controls:Label, GroupBox, ToolStrip, ToolStripItems, StatusStrip, StatusStripItems, PropertyGrid, ProgressBar, ComboBox, MenuStrip, MenuItems, DataGridView.

- Addressed a regression in accessible name for combo box items for data bound combo boxes. .NET Framework 4.8 started using type name instead of the value of the DisplayMember property as an accessible name, this improvement uses the DisplayMember again.

ASP.NET

- Disabled resuse of AppPathModifier in ASP.Net control output.

- HttpCookie objects in the ASP.Net request context will be created with configured defaults for cookie flags instead of .NET-style primitive defaults to match the behavior of `new HttpCookie(name)`.

SQL

- Addressed a failure that sometimes occured when a user connects to one Azure SQL database, performed an enclave based operation, and then connected to another database under the same server that has the same Attestation URL and performed an enclave operation on the second server.

CLR2

- Added a CLR config variable Thread_AssignCpuGroups (1 by default) that can be set to 0 to disable automatic CPU group assignment done by the CLR for new threads created by Thread.Start() and thread pool threads, such that an app may do its own thread-spreading.

- Addressed a rare data corruption that can occur when using new API’s such as Unsafe.ByteOffset<T> which are often used with the new Span types. The corruption could occur when a GC operation is performed while a thread is calling Unsafe.ByteOffset<T> from inside of a loop.

- Addressed an issue regarding timers with very long due times ticking down much sooner than expected when the AppContext switch "Switch.System.Threading.UseNetCoreTimer" is enabled.


1 Windows Communication Foundation (WCF)
2 Common Language Runtime (CLR)

Known issues in this update

ASP.Net applications fail during precompilation with error message

Symptoms
After you apply this October 13, 2020 Security and Quality Rollup for .NET Framework 4.8, some ASP.Net applications fail during precompilation. The error message that you receive will likely contain the words “Error ASPCONFIG.”

Cause
An invalid configuration state in either the “sessionState,” “anonymouseIdentification,” or “authentication/forms” sections of “System.web” configuration. This might occur during build-and-publish routines if configuration transformations leave the Web.config file in an intermediate state for precompilation.

Workaround
Customers who observe new unexpected failures or functional issues can implement an application setting by adding (or merging) the following code to the application configuration file. Setting either “true” or “false” will avoid the issue. However, we recommend that you set this value to “true” for sites that do not rely on cookieless features.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
      <appSettings>
          <add key=”aspnet:DisableAppPathModifier” value=”true” />
     </appSettings>
</configuration>

ASP.Net applications may not deliver cookieless tokens in the URI

Symptoms
After you apply this October 1, 2020 Security and Quality Rollup for .NET Framework 4.8, some ASP.Net applications may not deliver cookieless tokens in the URI, possibly resulting in 302-redirect loops or lost or missing session state.

Cause
The ASP.Net features for Session State, Anonymous Identification, and Forms Authentication all rely on issuing tokens to a web client, and they all allow the option for those tokens to be delivered in a cookie or embedded in the URI for clients that don’t support cookies. The URI-embedding has long been an insecure and disrecommended practice and this KB quietly disables issuing tokens in URI’s unless one of these three features explicitly requests a cookie mode of “UseUri” in configuration. Configurations that specify “AutoDetect” or “UseDeviceProfile” may inadvertently result in attempted and failed embedding of these tokens in the URI.

Workaround
Customers who observe new unexpected behavior are recommended to change all three cookieless settings to “UseCookies” if possible.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <system.web>
          <anonymousidentification cookieless="UseCookies" />
          <sessionState cookieless="UseCookies" />
          <authentication>
               <forms cookieless="UseCookies" />
          </authentication>
     </system.web>
</configuation>

If an application absolutely must continue using URI-embedded tokens and can do so safely, then they can be re-enabled with the following appSeting. But again, it is highly recommended to move away from embedding these tokens in URI’s.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <appSettings>
          <add key="aspnet:DisableAppPathModifier" value="false" />
     </appSettings>
</configuation>

 

How to get this update

Install this update

Release Channel

Available

Next Step

Windows Update and Microsoft Update

Yes

None. This update will be downloaded and installed automatically from Windows Update.

Microsoft Update Catalog

Yes

To get the standalone package for this update, go to the Microsoft Update Catalog website.

Windows Server Update Services (WSUS)

Yes

This update will automatically sync with WSUS if you configure Products and Classifications as follows:

Product:Windows 10 Version 1803

Classification: Security Updates

File information

For a list of the files that are provided in this update, download the file information for cumulative update.

Information about protection and security

Need more help?

Want more options?

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.

Was this information helpful?

What affected your experience?
By pressing submit, your feedback will be used to improve Microsoft products and services. Your IT admin will be able to collect this data. Privacy Statement.

Thank you for your feedback!

×