Security Bulletin
Microsoft Security Bulletin MS00-057 - Important
Patch Available for 'File Permission Canonicalization' Vulnerability
Published: August 10, 2000
Version: 1.0
Originally posted: August 10, 2000
Summary
Microsoft has released a patch that eliminates a security vulnerability in Microsoft® Internet Information Server. Under very restricted conditions, the vulnerability could allow a malicious user to gain additional permissions to certain types of files hosted on a web server.
Affected Software:
- Microsoft Internet Information Server 4.0
- Microsoft Internet Information Server 5.0
Vulnerability Identifier: CVE-2000-0770
General Information
Technical details
Technical description:
A canonicalization error can, under certain conditions, cause IIS 4.0 or 5.0 to apply incorrect permissions to certain types of files. If an affected file residing in a folder with restrictive permissions were requested via a particular type of malformed URL, the permissions actually used would be those of a folder in the file's parentage chain, but not those of the folder the file actually resides in. If the ancestor folder's permissions were more permissive than those of the correct folder, the malicious user would gain additional privileges to the affected file.
The vulnerability is subject to several significant restrictions:
- It only affects CGI scripts and file types that are implemented via ISAPI extensions. It does not affect static web page or non-web file types such as .exe, .doc or .bat
- It only affects servers that expose a web folder structure that mirrors the physical folder structure on the server.
- It does not allow arbitrary permissions to be selected, only permissions present on an ancestor folder
- It provides no way to enumerate the server and locate files that could be affected by the vulnerability.
Frequently asked questions
What's this bulletin about?
Microsoft Security Bulletin MS00-057 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
What's the scope of the vulnerability?
This vulnerability could cause the wrong permissions to be applied to a file on a web server. This could allow a malicious user to gain the ability to take actions - such as reading or executing files - that he otherwise would be denied.
The are several very important restrictions on the scope of the vulnerability:
- Only certain types of files are affected. In particular, static content such as HTML files are not affected.
- It only affects servers that are configured so that the web folder structure is an exact mirror of the actual folder structure on the server's file system.
- It could not be used to set arbitrary permissions - it could only be used to impose the permissions from the bona fide folder's parent, grandparent, etc.
- It would not provide a way for the malicious user to locate files on the server.
What causes the vulnerability?
The vulnerability results because of a canonicalization error affecting CGI scripts and ISAPI extensions. If an URL requesting either a CGI script or an ISAPI-mapped file - one located in a physical rather than a virtual folder -- were malformed in a particular way, the wrong permissions would be applied. Rather than applying the permissions for the folder that contains the requested file, those of an ancestor folder would be applied.
What's canonicalization?
Canonicalization is the process by which various equivalent forms of a name can be resolved to a single, standard name - the so-called canonical name. For example, on a given machine, the names c:\dir\test.dat, test.dat, and ..\..\test.dat might all refer to the same file. Canonicalization is the process by which such names would be mapped to a name like c:\dir\test.dat.
What's wrong with the canonicalization routines in IIS?
When certain types of files are requested via a specially-malformed URL, the canonicalization yields a partially-correct result. It locates the correct file, but concludes that the file is located in a different folder than it actually is. As a result, it applies the permissions from the wrong folder.
What folder's permissions would be applied?
It depends on where in the URL the malformation occurred. By selectively inserting the malformation into various locations in the URL, it would be possible for a malicious user to cause the permissions applied to the file be those of the parent folder, the folder above that, the folder above that, etc. - that is, those of any desired ancestor folder.
It's important to note that the vulnerability would not make it possible to apply any desired folder's permissions to a file. For instance, it would not be possible to cause a sibling folder's permissions be used, or those of an unrelated folder. Only the permissions for a folder in the direct line of parentage above the selected file could be applied.
Would this vulnerability allow the malicious user to select the permissions he wanted to apply to the file?
No. There is no capability through this vulnerability to apply arbitrary permissions to a file. The best he could hope for would be that a folder somewhere in the parentage of the file had the permissions he wanted.
What types of files are affected?
The vulnerability only occurs if either of two classes of files are requested: CGI scripts or any file type for which there is an ISAPI extension. .ASP is probably the best-known ISAPI-mapped file type, but it's also possible for users to create their own ISAPI extensions. In such a case, the custom-created file types also would be affected by the vulnerability.
The vulnerability does not affect static file types such as .htm, .jpg, or .gif. Similarly, it does not affect non-web file types such as .doc, .exe or .bat.
So, would this vulnerability apply to all CGI scripts and ISAPI-mapped files?
No. It's even more restricted than that. The vulnerability only applies to CGI scripts and ISAPI-mapped files when they reside in physical folders rather than virtual ones.
What do you mean by physical folders and virtual folders?
By "physical" and "virtual" folders, we're referring to whether the logical folder structure exposed by the web site corresponds to the folder structure on the server's file system. For instance, consider a file on a web server, named D:\inetpub\wwwroot\test1\test2\test.asp. The folder structure that the web server exposes can, at the administrator's discretion, mirror the actual location of the file or not.
Suppose the administrator set up the web server so that test.asp was available as www.microsoft.com/test1/test2/test.asp. In this case, the logical folder structure mirrors that of the server file system. This is an example of a physical folder, and such a case would be affected by the vulnerability. On the other hand, suppose the administrator had configured the web server so that test.asp was available as www.microsoft.com/windowsnt/information/test.asp. This is an example of a virtual folder, and such a case would not be affected by the vulnerability.
What would this vulnerability allow a malicious user to do?
If a malicious user could locate an affected file type (that is, a CGI script or an ISAPI-mapped file) residing on a physical folder, he could use this vulnerability to cause the permissions of any selected parent folder to be used instead of the bona fide ones. The specific damage he could do would depend on the particular permissions available in the ancestor folders.
For instance, suppose that the malicious user requested the file www.microsoft.com/test1/test2/test.asp, and the permissions on the test2 folder only allowed files to be executed. If the test1 folder allowed files to be read as well, the malicious user could exploit the vulnerability to read test.asp. However, if the test1 folder's permissions were identical to those of test2, he wouldn't gain any additional privileges.
Would this enable a malicious user to take control of a web server?
No. The vulnerability only applies incorrect permissions to file that are exposed via the web server. It does not provide any means of accessing system files or configuration information that resides on the server.
How would the malicious user be able to tell the permissions available from the ancestor folders?
He couldn't. He would need to iteratively exploit the vulnerability and determine the permissions by test.
How would the malicious user be able to tell whether any affected files were available?
Unless the folder's permissions already provided him with the ability to enumerate the files in it, he wouldn't be able to. That is, the vulnerability wouldn't provide him with a way to know that www.microsoft.com/test1/test2/test.asp exists, so he would need to determine this by some other means.
If someone exploited this vulnerability, would audit logs show what he had done?
Yes. This vulnerability has no effect on normal auditing, so the administrator would be able to tell exactly what the malicious user had done.
What does the patch do?
The patch eliminates the canonicalization error, so that the proper permissions are always applied when a file is requested.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.
What is Microsoft doing about this issue?
- Microsoft has delivered a patch that eliminates the vulnerability.
- Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
- Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
- Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.
Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.
Patch availability
Download locations for this patch
Microsoft Internet Information Server 4.0:
https://www.microsoft.com/download/details.aspx?FamilyId=344BFA19-F565-410E-8A9A-8BCBF3AAAABD&displaylang;=enMicrosoft Internet Information Server 5.0:
https://www.microsoft.com/download/details.aspx?FamilyId=4BF55FCC-F417-41D4-8E91-AE0832A0BC8E&displaylang;=en
Additional information about this patch
Installation platforms: Please see the following references for more information related to this issue.
- Microsoft Knowledge Base (KB) article Q269862, https:
Other information:
Acknowledgments
Microsoft thanks Burt Abreu & Søren Skov of VBExplorer.com for reporting this issue to us and working with us to protect customers.
Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
Disclaimer:
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
Revisions:
- August 10, 2000: Bulletin Created.
Built at 2014-04-18T13:49:36Z-07:00 </https:>