Farewell, EnableViewStateMac!

levibroderick

The ASP.NET team is making an important announcement regarding the September 2014 security updates.

All versions of the ASP.NET runtime 1.1 – 4.5.2 now forbid setting <%@ Page EnableViewStateMac=”false” %> and <pages enableViewStateMac=”false” />.

If you have set EnableViewStateMac=”false” anywhere in your application, your application will be affected by this change and you should read on. Otherwise there is no action you must take, and the behavior of your application will not be affected.

In December 2013, we released a security advisory warning that the configuration setting EnableViewStateMac=false is dangerous and could allow an elevation of privilege attack against the web site. At the time we issued a statement that the next version of the ASP.NET runtime would forbid setting this switch, and indeed when ASP.NET 4.5.2 was released it forbade applications from setting this insecure switch.

Along with the December 2013 advisory, we issued KB 2905247. This KB was an optional patch that customers could install if they immediately needed to deploy the “forbid setting this dangerous switch” logic throughout their infrastructure but couldn’t wait for ASP.NET 4.5.2.

Today we are enforcing this previously optional patch for all versions of the ASP.NET framework. If you are running the ASP.NET framework on your machine, this behavior will be picked up automatically the next time you check for updates.

We’re aware that this change could affect a substantial number of web applications. It is never our intention to break web applications in an in-place update, but we felt it necessary to address this issue head-on due to the prevalence of misinformation regarding this switch and the number of customers who are running with it set to an insecure setting.

Just what is a “view state MAC” in the first place?

MAC in this context stands for message authentication code, which is a cryptographic code generated by the server and appended to the __VIEWSTATE hidden form field. The MAC ensures that the client hasn’t tampered with these fields.

When EnableViewStateMac is set to true, this code is validated by the server when the client submits the __VIEWSTATE hidden form field during post back. This setting has been enabled (true) by default for all versions of ASP.NET.

Why forbid setting EnableViewStateMac=false?

We’re forbidding it because it is never safe to set EnableViewStateMac=”false”. As called out in the December 2013 advisory, an attacker may be able to leverage this setting to upload and execute arbitrary code on the web server. This would grant her complete control over the web application subject to the permissions of the web worker process.

After the initial advisory was released, we received questions from customers regarding conditional cases. What if I have set EnableViewState=”false”? What if I’m running over SSL? What if I’ve only set this on one page and it’s an admin-only page? What if my site just runs on the local intranet?

In all of these cases, the answer remains the same: not a single one of these “what ifs?” will prevent an attacker from exploiting this vulnerability. The web site is still open to remote code execution attack as long as EnableViewStateMac=”false” is present.

Will installing this patch change break my application?

If you have set EnableViewStateMac=false anywhere in your application, this change will affect you. Whether the new behavior breaks the application is scenario-dependent. If the reason the MAC was disabled was to enable cross-page posts, the application will generally continue to work correctly. If the reason the MAC was disabled was to avoid synchronizing the <machineKey> setting in a web farm, the application will probably break. See the below sections for more information on these particular scenarios.

If you are using EnableViewStateMac=true throughout your application, this change will not affect you.

Additionally, if you never touch the EnableViewStateMac switch at all in your application, this change will not affect you. Remember: the default value for this setting is true, and this change only affects applications where the developer has explicitly set the value to false.

What about cross-page posts?

Once KB 2905247 is installed, the ASP.NET framework treats cross-page posts specially to minimize the risk of errors at postback time. However, setting <form action=”some-different-page.aspx” /> has never been the recommendation for cross-page posts in WebForms. Consider using PostBackUrl instead to make this scenario work.

What if my servers are in a farm?

You are required to create a <machineKey> element and synchronize it across machines in your farm. See KB 2915218, Appendix A for full instructions on how to generate a <machineKey> element. That appendix contains a block of code that you can copy and paste into a PowerShell window. Then you can run the Generate-MachineKey command from within the PowerShell window to generate a <machineKey> element.

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

You can then copy and paste this <machineKey> element into your application’s Web.config file.

See KB 2915218, Appendix A for more information on the parameters that can be passed to the Generate-MachineKey function. See also Appendix C for information about using protected configuration to encrypt the contents of the <machineKey> element in the Web.config file.

Note: these keys are sensitive. Anybody who has access to them could end up with full administrative control over your web application. For this reason we suggest that you never use an online “click here to generate a <machineKey> element” utility. Only ever use <machineKey> elements that you generated yourself on your own machine. And use caution not to leak these keys in public places like online forums.

What if I encounter MAC validation errors as a result of this change?

We updated the “validation of view state MAC failed” error message to contain a link to KB 2915218, which lists common reasons that the MAC verification step might fail. Check that article to see if it calls out an item specific to your scenario.

Are there any other behavioral changes as a result of this?

Yes, there is a minor behavioral difference as a result of this patch, but this behavior will not break existing applications. If a __VIEWSTATE form field is written out to the response, it will now be accompanied by a new form field <input type=”hidden” name=”__VIEWSTATEGENERATOR” … />. This new form field is used by the ASP.NET runtime to help determine whether a postback is going to the same page or is cross-page. It’s similar in concept to the __PREVIOUSPAGE form field that is written when a control’s PostBackUrl property is set.

Is today’s rerelease of KB 2905247 different than the original December 2013 release?

Yes. The original release of the patch contained a bug where the value of the Page.IsPostBack property could be incorrect. The new version of the patch released today contains a fix for this issue.

If you are a server administrator and you have already deployed an earlier version of the KB, it is recommended that you deploy the latest version so that you get this bug fix.

What versions of ASP.NET is KB 2905247 applicable to?

This KB is applicable to all versions of ASP.NET from 1.1 through 4.5.1. The KB is not applicable to ASP.NET 4.5.2 or later, as the ASP.NET runtime already contains the patch built-in starting with version 4.5.2.

Why is KB 2905247 being made available on Windows Update now? Why not back in December 2013?

There are many factors that are taken into account when making a decision like this: the severity of the vulnerability, the number of customers who are vulnerable, and the impact of patching affected customers’ machines.

In the case of this specific vulnerability, the official Microsoft guidance many years ago was that web applications could sometimes get away with setting EnableViewStateMac=”false” in certain cases and that performance would be improved if the application were to do this. The original guidance was bad: this setting is categorically insecure, and this setting doesn’t improve performance. We have since corrected this guidance, but the damage was done. There was now a very large number of ASP.NET web sites which ran with this insecure setting.

Given the severity of the issue, when we released the original advisory back in December 2013, we wanted to push out the update to all customers worldwide and fix the issue immediately. However, given the large number of customers involved and the potential impact this change brings, we didn’t want to risk surprising customers with something this large. So we compromised: release an advisory stating that the configuration is insecure, allowing customers to proactively (rather than reactively) fix their sites. At the same time we made available to system administrators an optional patch which they could deploy on their servers to close the vulnerability outright.

It has now been nine months since the original advisory. This has given customers who wanted to secure their sites proactively ample time to test and deploy their changes. For our many customers who simply depend on the normal Windows Update / Microsoft Update mechanisms, however, the time has come for us to make sure that their applications are also protected against this.

Further resources

More information about the patch can be found at the original advisory page or on the Microsoft Support site.

Information about resolving “validation of view state MAC failed” error messages can be found on the Microsoft Support site under KB 2915218.

The ASP.NET team also maintains a document on common mistakes we see in typical ASP.NET applications and they can be corrected.

Finally, you can get in touch with us via the ASP.NET web site. We’re also active on StackOverflow. Prefer Twitter instead? The team is available at @aspnet.

Thanks for reading, and happy coding!

0 comments

Discussion is closed.

Feedback usabilla icon