ASP.NET Security Fix Now on Windows Update
Earlier this week I blogged about the availability of a patch on the Microsoft Download Center to fix the recent ASP.NET Security Vulnerability.
Today we also made it possible to update systems through Windows Update (WU) and Windows Server Update Services (WSUS). This enables administrators to more easily streamline patch installs, and enables you to take advantage of the WU/WSUS infrastructure to detect which patches you should install based on what versions of .NET are on your system.
Please make sure to install these updates as soon as possible on your servers. This will prevent attackers from using the vulnerability to attack your systems.
Using Windows Update
If you run Windows Update on your system you’ll see the security updates listed if you haven’t already installed them on your computer. Note that you’ll see a separate update available for each version of .NET you have installed on your system:
Please make sure all of the “Security Update for Microsoft .NET Framework” updates are selected and then apply them to keep your system secure.
Useful Notes and Frequently Asked Questions
In my blog post earlier in the week I answered a few commonly asked questions about the security updates. Below are a few additional notes based on help we’ve provided a few customers who have applied the update:
Do I Really Need to Apply this Update?
Yes. This update fixes security vulnerabilities that are publically known. You must install this update patch to be safe.
Make Sure You Apply the Update on All Servers in a Web-Farm
Because the patch modifies the encryption/signing behavior of certain features in ASP.NET, it is important that you apply it to all machines in a web-farm. If you have a mix-match of patched/un-patched systems you’ll have forms-authentication, webresource.axd, and scriptresource.axd requests succeed/fail depending on which server they hit in the farm (since the encryption used would be different across them).
Persistent Forms Authentication Cookie Behavior
After you apply the security update, visitors who have a persistent forms authentication cookie (the “remember me” scenario on login) will no longer be logged into your site – and will need to login again. The ASP.NET Forms Authentication system by default automatically handles this scenario for you – and will redirect visitors with a pre-patch forms-authentication cookie to the login page you’ve configured for your site. No error page is displayed – the behavior the end-user sees is the same as if the cookie had timed out. This is a good user experience and doesn’t require you to take any additional steps to ensure un-interrupted traffic to your site.
Note: We have had a few customers report problems with persistent forms-auth cookies that turned out to be issues either in their application code, or in a third party logging component they used. Specifically, this application code attempted its own decryption of the forms authentication cookie and threw exceptions when the cookie did not decrypt successfully. If after applying the security update you see issues with people who have saved forms authentication cookies visiting your site you might also be encountering this. There are two ways you can fix it: 1) update your code to not throw exceptions to end-users in these cases, or 2) modify the name of the forms-auth cookie that ASP.NET’s Forms Authentication system uses. Approach #2 is easy and doesn’t require any code changes - just modify the <forms name=".ASPXAUTH"/> configuration section in your web.config file and switch to a different cookie name. This will prevent your code from throwing exceptions because the old cookie failed to decrypt (instead the system will ignore the old cookie and issue all new cookies under the new cookie name you’ve configured).
Forms Authentication can continue to work across ASP.NET Versions
ASP.NET supports the scenario where you have multiple applications on a server, and share the same forms-authentication cookie ticket across all of them. It also supports the scenario where different applications on the site use different versions of ASP.NET. For example, one part of the site might be built with ASP.NET 2.0, another part with ASP.NET 3.5 SP1, and another part ASP.NET 4. This continues to be supported with the security update.
Note: If you are going to share the forms-authentication ticket across .NET 2 and .NET 3.5 SP1 or .NET 4.0 sites, then we recommend having .NET 2.0 SP2 installed to do so.
Make sure servers in a Web Farm use the same service pack of .NET 2 on all machines
We have seen an issue with a customer where they were running a site distributed across multiple servers in a web-farm, and some of the servers were running .NET 2.0 SP1 and others were running .NET 2.0 SP2. The URLs for webresource.axd and scriptresource.axd end up being different across the two Service Pack flavors when the security patch is applied – which can cause problems if your web-farm doesn’t consistently use the same service pack. You should make sure that the same service-pack of .NET 2.0 is installed across all the machines in a web-farm if they are running the same application across all of them.
How to Get Help If You Need It
You can ask questions and get help with the security vulnerability and update in a special ASP.NET Forum that we have setup here.
You can also contact Microsoft Customer Support for help with problems or questions (including support over the phone with a technical support engineer who can help you debug problems).
Thanks,
Scott