Microsoft Security Bulletin (MS00-007): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-007 announces the availability of a patch that eliminates a vulnerability in Microsoft® Windows NT 4.0. The vulnerability could, under very specific conditions, allow a malicious user to have inappropriate access to files in another user's Recycle Bin on the same machine. 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?
The vulnerability could enable a malicious user to create, modify or delete files in another user's Recycle Bin. In the vast majority of cases, it would not provide any additional opportunity to read files in the Recycle Bin. (This is discussed in more detail below).
There are some rather daunting obstacles that would significantly increase the difficulty of exploiting this vulnerability. For example:
| • | The malicious user would need to be able to interactively log onto a machine that the other user also interactively logs onto. |
| • | The malicious user would need to exploit the vulnerability before the other user had deleted any files. |
| • | The malicious user would need to know (or guess) the other user's Security Identifier (SID) |
Even if the malicious user could overcome these obstacles, the vulnerability would not allow the malicious user to read the files in the other user's Recycle Bin, nor would it provide a way to cause the user to retrieve a bogus file from it.
What causes the vulnerability?
Every Windows NT user's Recycle Bin maps to a folder whose name is unique to that user. Normally, Windows NT creates the folder the first time that the user deletes a file; however, if the folder already exists, Windows NT will use it, on the assumption that it was created during a previous session. When Windows NT creates the folder, it assigns permissions that only allow the owner to access it. However, it does not require that the permissions be set this way. As a result, if a malicious reader could create the Recycle Bin folder for another user on that machine, he or she could set the permissions in order to allow them read/write privileges to the folder.
How would the malicious user know what name to give the folder?
The folder name for every user must be unique, in order to ensure that two users never share a single Recycle Bin. To name is based on the owner's Security Identifier, or SID. SIDs are unique, but are not intended to be secret, and there are means by which to determine another user's SID. This would give the malicious user the information needed to create the appropriate folder.
What would happen if the user had already logged on and deleted a file?
The malicious user would be unable to exploit the vulnerability. The user's Recycle Bin would already be present, with permissions that don't allow any other user to access any data or change any permissions.
What's so bad about the malicious user being able to delete files from the Recycle Bin? Didn't the owner already delete them?
Yes, but by design the Recycle Bin should allow the owner to recover previously-deleted files. If the malicious user permanently deleted a file, the owner couldn't recover it.
What's so bad about the malicious user being able to insert files into the Recycle Bin?
It would offer a means by which to potentially introduce code or data of the malicious user's choosing onto the other user's storage. For example, suppose the malicious user inserted file RUNME.EXE into the other user's Recycle Bin. If he or she could get the other user to undelete the file and run it, it could take any desired action. The specific way that the malicious user would do this would be a question of social engineering.
Does this vulnerability provide an opportunity for a malicious user to read another user's deleted files?
In the vast majority of cases, it does not provide any additional opportunity for a malicious user to read another user's files. When a file is created, it inherits the permissions of the folder that it resides in. When a user sends a file to the Recycle Bin, it's executed as a rename operation, which does not change the permissions on the file. Thus, a file in the Recycle Bin will have whatever permissions it had when it was created, and these will match the permissions of the folder it was created in. This means that if the malicious user were able to read a file in the Recycle Bin, it's because the file was created in a file that he or she already had permissions to read. It's possible to hypothesize some very complicated scenarios in which this vulnerability would allow the malicious user to read a file that they otherwise would be unable to read-e.g., if the file had been created in a folder whose permissions were much less restrictive than its parent folder's, and the parent folder had not allowed traverse checking-but these are niche cases.
What machines are chiefly at risk from this vulnerability?
The vulnerability would primarily affect workstations and other machines that allow multiple users to interactively log onto them.
What if the user used several different machines?
The vulnerability would only allow the malicious user to take action against the files on the specific machine on which he or she created the bogus Recycle Bin.
Does the vulnerability affect Windows NT 4.0, Terminal Server Edition?
No. Terminal Server has different permissions on the C:\Recycler folder, and these would prevent the malicious user from creating anyone else's recycle bin.
Does the vulnerability affect machines that use FAT volumes?
It does affect them, but the vulnerability is a moot point for machines with FAT volumes. By design, anyone who can log onto a machine using a FAT volume can view all of the files on it. The lack of filewise permissions is one reason why we recommend using NTFS volumes as a best practice.
What does the patch do?
The patch eliminates the vulnerability by checking the permissions on the user's Recycle Bin every time a file is deleted. If anyone but the owner has permissions to it, Windows NT will delete the Recycle Bin and create a new one with the correct permissions. This would cause the contents of the Recycle Bin to be lost, but this is the proper course of action because the contents would be suspect. Does this vulnerability affect Windows 2000? No.
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 SHELL32.DLL has the following properties... |
Intel | Date: January 18, 2000 |
Alpha | Date: January 18, 2000 |
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 a Knowledge Base article explaining the vulnerability and patch in more detail. A link to the article will be posted here as soon as the article is available. |
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 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.
