Finally they’ve delivered! Earlier today the much awaited padding oracle patch was released by Microsoft. As usual, Scott Guthrie has written about it and you can find all the info in ASP.NET Security Update Now Available.
It’s not a moment too soon either. According to Thai Duong, half of the duo responsible for bringing the vulnerability in ASP.NET to public awareness, the guidance Microsoft has provided over the last couple of weeks was, well, a waste of time. And here’s another video to prove it:
Don’t trust your hosting provider!
Hosting providers everywhere should now be rushing to apply the patch. I’m sure many of them are offering assurances that work is well underway and the vulnerability will soon be a thing of distant memory. Personally though, I need a little more assurance for something as potentially catastrophic as this.
Here’s how to test it
Firstly, there may be a better way to test for the existence of the patch (in fact it’s quite likely), and I’d still like to find a way to do this remotely without making changes to the app. But having said that, this is one of those time-critical issues and on that basis this is info worth sharing early. I’ll update the post if someone can provide a better mechanism.
The easiest way I’ve found to test for this is to turn custom errors off (I know, but this is going to be very brief) and hit the app with this address:
http://[my domain]/WebResource.axd?d=zt87v2JeCPKYzqUfGEffpA2
This address contains valid ciphertext from another app but will fail in any other environment.
Without the patch installed, a CryptographicException will bubble up to the browser in a yellow screen of death:
With the patch installed, the same request will now return a 404:
Summary
Like I said earlier, I’m sure there’s probably a better way of doing this and I’d really prefer not to be turning off custom errors in a production environment, but for the sake of maybe a 30 second window which verifies this important patch has been applied, it’s not a bad trade-off. You could also leave custom errors on and just remove the default redirect page and assume the 500 server response implies padding was invalid, but of course there could be another underlying error causing this response.
Happy patching :)
Updates
Update 1: Thanks to Neal Blomfield for pointing out that elmah can email the underlying error message while preserving the custom error page facing the user. Likewise, you can natively do this with ASP.NET Health Monitoring. A more user friendly approach if you can wait a small moment for the email to come through.
Update 2: A slightly less explicit but also less publically revealing approach is to define a different custom error page for 404s (it’s apparently now safe to do this again) and ensure that’s the page that is returned when the CryptographicException is thrown.
Update 3: Kristofer Andersson has explained that due to the inclusion of a signature in the resource ID of the Web.Resource.axd, the “d” parameter has now increased in length. For example, the same reference on the same page before the patch:
WebResource.axd?d=Af39_uT4CxOkzOaoKMa4hw2
And then after the patch:
WebResource.axd?d=zM_1kYJhWvigh3vC7lA4N2N4h7tslEsHlpZCZn7MMGvJL0BOb7niar-
Le9c6mo0rv-PNgBEyIMfvYNxOJVrY2ekAW0Es0R9CD36k8OT92YI1