For those of you who don't know .net, this is basically where all the site specific configuration files lie - think database passwords, email servers, admin passwords to bootstrap the system, etc.
Indeed, but if you're doing it right, you won't have any passwords there. The things you need to access from a web app tend to allow trusted user access, so all an attacker would be able to get from a properly configured site's web.config would be the name of the database server (or the fact that it's (local)).
This doesn't seem like something worth worrying about to me.
In order for this to happen to your site, you would have to have CustomErrors turned off, or otherwise have your site set up to display stack traces to the general public. That's a quick recipe to get your site hacked regardless of technology, so the fact that it leaves you a little more open to a specific type of crypto attack is neither here nor there.
So basically, if you're following best practices (not just for ASP.NET, but web dev in general) and not displaying stack traces to your users, you're not in danger of this happening to you.
Reading into it, it is not enough to just have CustomErrors on to mitigate the risk. There are some pretty detailed instructions, involving pushing all errors to a single page, with a random delay embedded in the page script.
They seem intentionally vague about how someone can use this to get asp.net to dump the web.config however.
The recommended temporary patch is horrible. They want servers to return 500 error with exactly the same message no matter what the problem is. That means 404 and any other custom error can't be returned to the user. The user has no idea what just happened and why they're seeing the error.
A patch is on the way to eventually make this unnecessary but there's absolutely no ETA for it. Are we talking days, weeks, (gasp) months? They do deserve credit for responding to the comments but it would be good to have a better ETA.
The article is a bit vague there, bit I didn't read it to mean you couldn't distinguish 404s from 500s.
It seems to say that you shouldn't tell people which flavor of 5xx he got, since that's useful info to an attacker.
As I mentioned in another thread, this doesn't seem like it would affect any real sites, so it's not a case of waiting for (gasp) months for a patch while your server is in real jeopardy.
Security warnings like this come through for ASP.NET a couple times a year, but nearly all of them are of the "don't do the stuff you already shouldn't be doing, or bad things might happen" variety.
7 comments
[ 2.3 ms ] story [ 36.4 ms ] threadSo this is kind of a big deal.
In order for this to happen to your site, you would have to have CustomErrors turned off, or otherwise have your site set up to display stack traces to the general public. That's a quick recipe to get your site hacked regardless of technology, so the fact that it leaves you a little more open to a specific type of crypto attack is neither here nor there.
So basically, if you're following best practices (not just for ASP.NET, but web dev in general) and not displaying stack traces to your users, you're not in danger of this happening to you.
They seem intentionally vague about how someone can use this to get asp.net to dump the web.config however.
A patch is on the way to eventually make this unnecessary but there's absolutely no ETA for it. Are we talking days, weeks, (gasp) months? They do deserve credit for responding to the comments but it would be good to have a better ETA.
It seems to say that you shouldn't tell people which flavor of 5xx he got, since that's useful info to an attacker.
As I mentioned in another thread, this doesn't seem like it would affect any real sites, so it's not a case of waiting for (gasp) months for a patch while your server is in real jeopardy.
Security warnings like this come through for ASP.NET a couple times a year, but nearly all of them are of the "don't do the stuff you already shouldn't be doing, or bad things might happen" variety.