Is ASP.NET MVC vulnerable to the oracle padding attack?

Question

Is ASP.NET MVC 2 vulnerable to the oracle padding attack? If so, what workaround should be implemented? The instructions on Scott Gu\'s blog appear to only be for Webforms

Answer 1

Do you have a route/controller action setup to return an error page for the /Home/ErrorPage route?

Answer 2

This question is included in Scott Gu's Frequently Asked Questions about the ASP.NET Security Vulnerability:

Does this affect both ASP.NET Web Forms and ASP.NET MVC?

Yes – the publicly disclosed exploit can be used against all types of ASP.NET Applications (including both Web Forms and MVC).

Answer 3

Yes - linkage to the comment by Scott Guthrie.

Saturday, September 18, 2010 9:00 PM by ScottGu

@Vijay,

Will the ASP.NET MVC too get affected?

Yes - all versions of ASP.NET are affected, including ASP.NET MVC.

Thanks,

Scott

I see that you've seen the comment, but if you run the vbs script on your server, it should tell you if it's still a problem.

Edit: Also, Scott has discussed FAQs in a new post here.

Answer 4

Under your default route you could/should add this for starters

routes.MapRoute("Catch All", "{*path}", new { controller = "Home", action = "ErrorPage" });

Edit 2

the problem lies in the part redirectMode="ResponseRewrite" without this, it works.

using the route though will fix 1 part of the problem, where the path cant be found (404)

the next part, like existing paths with bad ID's or other data, could be fixed with

<customErrors mode="On" defaultRedirect="/Home/ErrorPage" />

what exactly does redirectMode="ResponseRewrite" do?

Edit: what it does.

redirectMode

• ResponseRedirect: Specifies that the URL to direct the browser to must be different from the original Web request URL.
• ResponseRewrite: Specifies that the URL to direct the browser to must be the original Web request URL.

It only matters for .NET 3.5 SP1 and .NET 4.0.

Edit 101:

For redirectMode="ResponseRewrite" the ASP.NET calls Server.Execute(...) internally, which does not work with MVC routes, so for MVC this only works with a static HTML file.

<customErrors mode="On" defaultRedirect="~/Views/Shared/error.htm" redirectMode="ResponseRewrite" />

works.

Answer 5

A patch for this bug has been released on Windows Update.

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Answer 6

I posted my full take on this (after extra research) on my blog.

Update note: moved the link to a post specific to asp.net MVC

---

I strongly believe the issue with the 404s is related to WebResources and ScriptResources (which can disable for asp.net MVC btw), as those probably give 404s when the corresponding resource isn't found (which would be the normal response to an valid padding that gives an invalid resource path/name).

Other error codes & messages could be an issue for other asp.net features, but ending with a 404 only because you hit an url non related to any special handler shouldn't be causing the issue.

Also note what I mentioned in this answer: How serious is this new ASP.NET security vulnerability and how can I workaround it?

if the app is asp.net MVC we don't really need webresources.axd and/or scriptresources.axd, so those can be turned off. We also don't use viewstate.

asp.net membership provider 'caches' roles in cookies, turn that off.

The auth cookie is signed, and from the info in the paper they shouldn't be able to generate a signed cookie if they don't get to the actual keys (as they did in the video before forging the auth cookie).

As Aristos mentioned, for the session id in the cookie, that's random for the user session, so it'd have to be sniffed from an user with the target security level and cracked while that session is active. Even then if you are relying in authentication to assign/authorize the user operations, then the impact would be minimal / it'd depend a lot in what Session is used for in that app.