Invalid Viewstate since ASP.NET Oracle Padding Vulnerability Security Patch

Question

Since installing the security patch for the ASP.NET Oracle Padding vunerability any user that was keeping themselves logged in to our site is getting error messages when hitting any page.

The errors logged on the server are

System.Web.UI.ViewStateException: Invalid viewstate. 
Client IP: xxx.xxx.xxx.xxx
Port: 55796
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
ViewState: l4nsXEvWcOwlDpmdbxw916bpHoPiqdBP7Syb+zCQAv44xv/r3oLtETKTL28/Gts6
Referer: 
Path: /product/4795/fender-usa-deluxe-stratocaster-mn-olympic-white-pearl

With custom errors switched off a user sees the following information

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Source Error: 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.  

Stack Trace: 


[ViewStateException: Invalid viewstate. 
Client IP: xxx.xxx.xxx.xxx
Port: 3588
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.5; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
ViewState: s0toPCu7bxkB7a3G+KTxawY3ILf1qunZyIqNBKg8xSoqY2BkWIUCJAHKFKo2RnJw
Referer: 
Path: /]

[HttpException (0x80004005): Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +118
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +13
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +238
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) +5
System.Web.Mvc.AntiForgeryDataSerializer.Deserialize(String serializedToken) +90

The solution to this problem is to delete all cookies and log back in, but obviously an average user, won't know to do this and I'm worried they will just think our site is broken.

Is there anything I can do about this like force people who were logged in to log in again?

Thanks for any help you can be

Answer 1

There is probably no avoiding that. If they changed the key generation/validation code, all of the currently generated key cookies will now be invalid.

You could capture the exception by using a error handle in global.asax (or a httpmodule), and attempt to remove the forms authentication cookie from the users computer.

That may cause things to work.

Answer 2

I say this with no knowledge of the vuln. or the patch but:

If it is happening within the application try catching the exception(s) that cause the error page and put up a custom page explaining the steps required to proceed. If it is happening at the server there may be a whole bunch of settings (within IIS) that may or may not be of any use.

Answer 3

what you are describing doesn't look like invalid ViewState but invalid authentication cookies.

if you are positive it is the ViewState, then they are submitting pages they had opened in their browsers / it doesn't have to do with the cookies.

As for auth cookies I'd expect asp.net authorization to redirect to your login page. Are you doing anything custom with the auth tickets/cookies?