Last post Sep 28, 2010 03:55 PM by Rovastar
Sep 28, 2010 03:29 PM|pitz|LINK
Now that the patch is out, I'd like to note that the <customErrors> handling does not, by itself alone, thwart the padding oracle exploit. The intent of the workaround was to redirect to a common page depending on the caught exception.
Someone in the forums already alluded to this -- by appending an "&aspxerrorpath=something" in the HTTP request to the padding oracle, the <customErrors> handling is bypassed and the attacker still gets to distinguish between a padding error and a regular
A better workaround is to have a global application error handler that performs the redirects, similar to what <customErrors> does, but without the bypass when the "aspxerrorpath" parameter is present.
However, if you can, just get and test the released patch.
Sep 28, 2010 03:55 PM|Rovastar|LINK
Yeah I spotted that a week ago and I was emailing Microsoft as I am sure a few others did.
The patch doesn't fix what I assume is a bug in the way asp.net returns error pages when you place the &aspxerrorpath= in the path but it returns just a 404 page when presented with a 500 error which was the vulernability.