locked
customErrors section workaround is not enough; get patch RRS feed

  • Question

  • User-1828574268 posted

    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 error.

    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.


    Tuesday, September 28, 2010 3:29 PM

Answers

  • User-234406897 posted

    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.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 28, 2010 3:55 PM