Public disclosure of IIS security issue with semi-colons in URL

IIS has been alerted to the claim of a new security issue in IIS 6 and I wanted to explain the issue and our position on it.

The issue in question affects only IIS 6 (Windows Server 2003) and arises when you send a URL with a semi-colon in it. IIS 6 uses the path before the semi-colon to determine the script handler for it. So sending a URL like http://www.fabrikam.com/uploads/foo.asp;bar.jpg results in mapping this request to the ASP script handler since it ignores everything after the semi-colon. In the case where this URL is given Execute Permissions, we will end up executing the ASP script inside a file "foo.asp;bar.jpg".

Here are the facts concerning this issue:

  1. You MUST have write permissions to upload your content. The issue being discussed here does not let you bypass that requirement. So if you don't allow uploads, read no further, you are not exposed to the issue.
  2. If you allow uploads of files then IIS best practices require you NOT to give script permissions to an upload folder (see bullet point 7 in the link). In the case that you follow best practices and not grant script permissions to an upload folder, there is no room for any script being executed. Requesting a URL like http://www.fabrikam.com/uploads/foo.asp;bar.jpg on a properly configured server will result in a 403 error. Hence there is no security issue on a properly configured server either.
  3. If your server uses an non-recommended configuration and allows uploads and script execution privileges together, then only those authorized to actually upload content will be able to place said content. And in this case the existence of this issue is of no major import in letting you execute your script ... since that is exactly what you have configured your server for.

In summary, there is a functionality issue here, but there is no security issue unless you already had a poorly configured server to begin with.

6 Comments

  • Mike, I do not want to diminish your concerns. But the fact remains that default IIS config does not have Write+Execute Permissions. You need to go out of your way and configure this when you create an upload folder. So the "by default" argument does not hold. We are not absolving ourselves of any responsibility here, just making sure accurate information is out there.

  • The physical directory that files are uploaded to is distinct from the web site's physical directory. This directory allows read and write permissions.

    Does this setup adequate for the issue addressed in this post?

  • Mike,

    I just want to confine what nazim said.

    Normal usage in a hosting environment you would have say scripts enable and in a few cases execute permissions enabled.

    However you would really have write access enabled. That must be bad practice to do this.

    Write access is the key here. If you do allow the write access then you should more carefully monitor your configurations.

    I would write a script to get all the setting of your sites to see what has write access enabled and look at the execute permissions for those.

    =========

    Tuesday, December 29, 2009 11:45 PM by Mike Graves

    You guys(MS) are dead wrong. This is a real security vulnerability. In a default config in IIS6 you can easily create test.asp;hack.jpg and run it with success. Now you'll recommend that upload directories be set to Execute Permissions = None but in the shared hosting world no one can be sure of what their customers are doing. This is a huge hole. Thanks for the job security! I'll now be auditing thousands of shared hosting sites and do my best to secure them.

  • Daniel, def59485
    There are 2 different sets of permissions NTFS file permissions for physical location and IIS permissions for virtual location. On IIS6, the IIS permissions are in the accessFlags property and on IIS7 and above they are in the accessPolicy flag of the handlers section. Both of these are honored, so think of it as an AND operation where the NTFS permissions will win if the IIS config says otherwise. The configuration you need to be concerned about is when you give Write permissions to a folder, Read is not that interesting here. In the case you give Write permissions you need to make sure that the IIS permissions do not grant script permissions to that directory ... script permissions are an IIS config property, not an NTFS property. HTH.

  • @Andrew, XenoMuta

    We never claimed that this is not an issue. All we are saying is "bug with security implications != security bug"

    Shared hosting companies usually give you upload via FTP for your content, not HTTP. Your vdir in this environment defaults to RX permissions and don't have write. So your statement about hosting companies isn't accurate.

    The Apache issue you speak of is a web application issue, not an Apache server issue IIRC. There are plenty of bad apps on IIS as well ... but their misconfiguration does not inherently become an IIS security issue.

    We are not trying to dodge the issue by saying "you are not following security best practices". This is the oldest tenet in web server management! Don't give uploaded content permissions to execute unless you tightly control AuthN/AuthZ/Audit. Semi-colon issue is irrelevant when you have this configuration. Let's say we fixed the semicolon issue and then you found another way to bypass the web application's whitelist, then what? You will still end up executing script ... because YOU gave that permission on the folder.

    Remove execute permission on the upload folder and problem is gone ... semicolon or no semicolon.

  • @Bryan: KB 979124

Comments have been disabled for this content.