Last week a flaw in IIS 6 was revealed. If an attacker can place a file with a name like "semicolon.asp;.png" in a folder which has Execute privileges, then IIS 6 will treat the file not as a PNG file, but as an executable ASP page.

The CMS400.net CMS, at least as of 7.5.x, allows CMS users to upload files with semicolons in their names, and Library files preserve the initial user-supplied file name. On both our production systems and my local CMS400Developer site, the "uploadedfiles" and "uploadedimages" directories had "Scripts only" execution permissions set.

So I expect that most cms400.net installations are at some risk. Anyone who can upload a file and specify its name -- most obviously CMS workarea users with rights to the Library -- can exploit this flaw. We don't use any of the blog, forum, or other features that target "external" users, so I'm not in a position to evaluate those features. I'm also not in a position to assess cms400.net versions 7.6 or 8.0.

The workaround is to restrict execute privileges. As far as I can tell, the /Assets, /UploadedFiles, and /UploadedImages directories don't need execute permission, so just set those directories' "Exectute permissions" to "None". IIS will still treat "/UploadedFiles/semicolon.asp;.png" as an ASP file, but instead of executing, IIS will now throw a 403.1 Forbdden error. If you're using multisite, you will want to ensure that your virtual directories also have None for execute permissions.

BTW, Microsoft's current position is that this is not a flaw but an "inconsistency", and one that is not exploitable if the IIS site is configured following best practices, but they're missing a detail. Their best practices seem to say not to give IIS write privileges on a folder with any execute permissions set, but the problem here is that the ASP.Net app has write privileges, not IIS. Anyhow, don't expect a fix from Microsoft very soon.

Since all our cms400.net systems have execute permissions on the Library directories, frankly I fault Ektron for not revoking execute permissions at install time; they should have understood the underlying principles behind the IIS best practice recommendation and realized that hey, since we ARE writing "dead content" to the Library, we should revoke execute permissions. Anyway, that's the zero-progress blame game. Enough of that. Change those folder permissions in the IIS management console and move on.

-Peter