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