Mitch Sellers wrote:
Rick,
I am going to disagree with you a bit here.
1.) Hosting companies and site administrators have the ability on a website by website basis to enable and disable services for each site. Part of proper IIS security baselines SHOULD BE to ensure that no services are running or supported that are not needed. For example no .asp or .php if you are .NET only. Yes, if a site is running a mix, etc that is something else to deal with.
2.) I will agree that this is an issue, but in all reality, not something that is 100% DNN's responsibility to manage. How would DNN support this, other than to potentially prohibit uploading files that contain a ; character. The reason I say this is if the file has two extensions, which to we "accept", which is there.
This is an overall security concern at the server level, in that the server, processes files in a way that is considered un-natural. Should DNN or other web-applications correct against this if possilbe? Sure, but this is not a DNN issue.
Secondly, no matter how much you protect your site, extension limiting alone, is NOT something that is 100% foolproof. To your point of internal, malicious users with access that you have given them permissions, they can still do things...
Mitch,
I wasn't clear in that I don't think DNN should be doing anything to prevent this. I only presented this information so that everybody can be aware of it. Indeed today was the first time I had heard about it, and when I saw it, my first thought was UH OH. NOT GOOD. Microsoft's response that it isn't that big of a deal IMHO isn't the best response to it either. One thing I've learned in my years of development is that no company is unique and other companies are dealing (or are going to be dealing) with the same issues as all the others. Since I know how my machines are configured (and for what reasons) I'm certain there are other companies that have machines configured the same way)
The reason I brought it up here is because of the way I understood DNN is to be configured, and because of the defaults that are created when you create a site in IIS. You are right in that the admin CAN remove the ISAPI extension mapping for ASP in IIS, however if ASP is turned on for the server, by default when you create a new website the ASP ISAPI mapping is created for you (I'm not sure what happens if ASP is turned off, I didn't test it). If you don't know about this exploit then you are potentially vulnerable when you install a DNN site. It's the simplicity of this exploit that is scary. It doesn't require knowledge of buffer overflows or other more esoteric methods of attacking a machine. All it requires is the ability to upload to a DNN site (and have ASP active on the host machine). If the community is AWARE of the issue then they can take steps to prevent it from happening.