Microsoft Security Bulletin (MS99-061): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS99-061 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server and, by extension, in Microsoft products that incorporate it such as Microsoft Site Server. The vulnerability does not directly affect any of these products; its only effect would be on certain third-party software that runs atop these products. On affected third-party products, the vulnerability could allow a malicious user to bypass file access controls. Microsoft takes security seriously, 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 lies in IIS, but it has no security ramifications for IIS. Its only effect is on certain third-party software packages that run atop it and do not handle file accesses through it. For affected third party products, the effect of the vulnerability would be to allow a malicious user to access files that he or she ordinarily would not have permission to view, by specifying the file name via an alternate form.
What causes the vulnerability?
By design, IIS allows URLs to contain hexadecimal data. The hexadecimal data is specified by preceding it with a percent sign (the so-called escape character), and is generally used as a way of providing special ASCII characters within an URL. For instance, %20 indicates the hexadecimal value for a space character in ASCII.
By design, only valid hexadecimal digits (0-9, A-F) should be accepted when preceded by a percent sign. However, IIS actually parses non-hexadecimal digits, and sometimes maps them to ASCII characters. For example, %3p maps to the character "I". This provides an alternate way of specifying a file name. For instance, the URL //server/confidential/secret.asp could also be specified as //server/conf%3pdential/secret.asp.
What would happen if someone requested a file via this alternate form?
It depends on the particular application. It has no effect on IIS or any Microsoft product that runs atop it; these products resolve all renditions of the file name to a common representation before applying any access controls. (This process is called canonicalization).
However, some third-party applications that run atop IIS do not canonicalize file names before applying access controls. For instance, in the above example, an affected third-party product might have "no access" set for the file //server/confidential/secret.asp. Upon receiving a request for //server/conf%3pdential/secret.asp, it might not recognize this as the same file, and grant the access request.
How do I know whether I have an affected third party product?
If you are running any third-party product atop IIS, you should assume that it is affected. Even if it currently is not, there is no guarantee that a future version of the same product wouldn't be affected. Likewise, you might choose to install another third-party product that is affected at some future point.
What damage could a malicious user do via this vulnerability?
It's impossible to say precisely. It would depend on the specific third-party application, and what it allows the user to do. For instance, if the third-party application were one that only allowed the user to view files, the risk from this vulnerability would be significantly less than if a third-party application were in use that allowed files to be changed.
Does this vulnerability affect the version of IIS in Windows 2000?
No.
What does the patch do?
The patch eliminates the vulnerability by restricting the characters that can follow a percent sign in an URL. It allows only legitimate hexadecimal digits to be specified.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
How can I tell if I installed the patch correctly?
Use the following table to verify that you've installed the patch correctly.
| If you're running on the following platform... | You've installed the patch correctly if W3SVC.DLL has the following properties... |
Intel: | Date: November 17, 1999 |
Alpha: | Date: November 17, 1999 |
What is Microsoft doing about this issue?
| • | Microsoft has developed 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 patch. |
| • | 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 Knowledge Base articles explaining the vulnerability and patch in more detail. |
Where can I learn more about best practices for security?
The Microsoft Security web site is the best to place to get information about Microsoft security. A comprehensive checklist for securing IIS servers is available at http://www.microsoft.com/technet/security/chklist/iischk.mspx.
How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.
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.
