How was the oracle padding attack on ASP.NET Fixed?

Question

Microsoft released their out of band release to fix the security flaw in ASP.NET the yesterday.

What methods did Microsoft use to end the viability of this vector?

Answer 1

A great summary of the changes comes from http://musingmarc.blogspot.com/2010/09/ms10-070-post-mortem-analysis-of-patch.html

• Don't leak exception information - This prevents exploits from seeing what is broken.
• Don't short-circuit on padding checks (take the same amount of time for padding correct verses padding broken) - This prevents exploits from seeing timing difference for incorrect padding.
• Don't be too picky about exception catching in IHttpHandler.ProcessRequest - This prevents exploits from seeing that you caught one kind of exception (CryptographicException) instead of all exceptions.
• Switch from Hash-based initialization vectors to Random IVs - This prevents exploits from using the relationship between the data and the hash to decrypt faster.
• Allow for backward compatibility - In case this breaks something, allow the new behavior to be reverted in-part.
• When doing a code review pass, change to make it clear you've considered the new options.

Answer 2

The main: sign any encrypted data that is sent to the browser. This prevents messing with the values like the attack did to gain information on valid vs. invalid padding i.e. since the signature won't match in all those cases.

Its important to note, the hole in webresource and scriptresource that allowed files retrieval shouldn't have happened. Simple encryption alone isn't meant to tamper proof. In other words, it wasn't an oversight of an advanced scenario like the rest of the padding oracle attack (which still relied on the same fact, sending back modified encrypted data to the app with no tamper proof protection on the server).

Besides the main fix above, expected things like trying to hide further encryption side channels and making sure it doesn't break other features that rely in the same encryption calls (like asp.net membership).

Answer 3

The vulnerability relates to flaws introduced by CBC Padding. The full theory behind the attack can be found here. However you must first read up on block cipher modes of operation.