Hello Matt - With all due respect, if NTFS permissions are not configured properly then you have many, many things to be worried about aside from having Parent Path being enabled or disabled, particularly if you are allowing people to upload executable files remotely (as in, the server is a shared hosting server). In this scenario, a user can literally upload a very simple ASP script that utilizes FSO and they can delete every single file on the server. Would disabling parent paths help you at all in this case? Absolutely not - because it's would be possible to specify the drive root and begin recursively deleting files using some loops. Furthermore, if hackers are exploiting poorly coded web applications that allow executable files to be uploaded and you insecure NTFS permissions, your server is screwed, regardless of having Parent Paths enabled or not.
Please also understand that second scenario that you note is also related NTFS permissions being insecure. With proper NTFS permissions, one customer cannot access another customer files. This is the whole point of permissions. Without proper permissions in place, your server is a sitting duck. Goodness gracious. -Jay ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, April 03, 2006 6:27 PM To: [email protected] Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out Kevin, IIS 6 has built in protection from double encoding by default (like "..%5c" or ".%2e/" instead of "../"), and I also still use URLScan to block such things even though Microsoft was saying that it wasn't necessary with IIS 6. The other important addition in IIS 6's security is in only allowing explicitly defined extensions to be returned, and by default, extensions like EXE are not configured. I also don't use default locations, I remove all example code, and I give Web sites the bare minimum permissions. Jay, one of the issues with parent paths is the fact that permissions are sometimes configured to allow Everyone access. Script kiddies often deface or hack servers by exploiting poor code and file permissions of popular Web applications. For instance, a lot of the phishers are putting their content on sites where PHP-Nuke is used, and there has been a long history of hacks for all sorts of content management and bulletin board code. Often the attacker adds the directory transversal string as an argument to a script. Another very big issue with such a configuration is that Parent Paths can allow an admin for one website to write a simple script that escapes their root and read or write content from/to another site (depending on permissions). For instance, someone could look for a common file in another site such a web.config, and read the SQL Server login and password, and then steal or corrupt another customer's data in the database. Simple as pie! The best security is to explicitly define the minimal permissions necessary for every unique site use, and to layer your security. Declude can get around the limitations of disabled Parent Paths by requiring a virtual directory to be created, and using a specific Group with explicitly defined permissions to access the required files. This is not a big deal to do. Matt Kevin Bilbee wrote: Install url scan and use the IIS lockdown tool. this will stop all ../../../ attacks dead in their tracks. Rerardless of the parent paths setting. Kevin Bilbee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matt Sent: Monday, April 03, 2006 2:38 PM To: [email protected] Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out Jay, This is incorrect. You can traverse directories within your root using "../" with Parent Paths disabled, but if you enable it, you can go outside your root so long as the file permissions allow it. Here's a quote from the KB article that you linked to: "The Parent Paths option (the AspEnableParentPaths metabase property) permits you to use ".." in calls to functions such as MapPath by allowing paths that are relative to the current directory using the ..\notation. Setting this property to True may constitute a security risk because an include path can access critical or confidential files outside the root directory of the application." Matt Jay Sudowski - Handy Networks LLC wrote: Wrongggggggggg. Enabling parent paths doesn't allow you to actually enter ../../../../../ and transverse directories into your URL string! http://support.microsoft.com/default.aspx?scid=kb;en-us;332117 It simply allows you to use ../ in your ASP and SSI includes! Goodness gracious. PS - Please use plain text unless you have a particularly compelling reason to post in HTML. ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, April 03, 2006 5:27 PM To: [email protected] Subject: Re: [Declude.JunkMail] Declude 4.1 Is Out I beg to differ. IMO, Enabling Parent Paths is one of the biggest security risks for a Web server, and IIS disables them by default because of this. Most exploits require multiple configuration mistakes to exploit, and if you enable Parent Paths, it increases your likelihood of being hacked many times over. If you look at your logging of websites on your server, you will likely see entries around 200 at a time from script kiddies, most of which are seeking to exploit configurations where parent paths are enabled. The proper way to approach this would be to create a virtual directory under the website, and configure an exclusive group as having permissions for the Declude directory. Matt Jay Sudowski - Handy Networks LLC wrote: Practically speaking, the security risks related to parent paths are near zero. On scale of 0 to 100, having parent paths enabled would be a .01, assuming your NTFS permissions are tight. -Jay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Monday, April 03, 2006 5:09 PM To: [email protected] Subject: RE: [Declude.JunkMail] Declude 4.1 Is Out >From the readme.html: "Parent paths must be enabled." Sorry, no they will not be enabled. That is a security risk I am not going to open up on my server. John T eServices For You "Seek, and ye shall find!" -----Original Message----- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Jay Sudowski - Handy Networks LLC Sent: Monday, April 03, 2006 1:45 PM To: [email protected] Subject: [Declude.JunkMail] Declude 4.1 Is Out http://www.declude.com/Articles.asp?ID=186 Aside from the web admin, are there any other fixes or feature enhancements? The release notes reference 4.0.9.4 ... Thanks! ----- Jay Sudowski // Handy Networks LLC Director of Technical Operations Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting Solutions Tel: 877-70 HANDY x882 | Fax: 888-300-2FAX www.handynetworks.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
