NT Recycle Bin Goes Unchecked

According to Arne"s report posted on the Win2KSecAdvice mailing list,

"There is a vulnerability (though it"s not incredibly dangerous, but
anyway...) in the implementation of the recycle bin in Windows NT and Windows 2000. It was noticed both by me and Nobuo Miwa.

I"ll explain it with an example:

Say that you have a volume c: where the recycle bins are stored under c:\recycler. All users must have permission to create new directories there because the first time a user throws something into the recycle bin, a directory is created in c:\recycler, which is named with the user"s SID. This is done in the security context of the logged on user.

Imagine that there is one user A (attacker) and another V (victim), and that A logs on before V has thrown anything into the recycle bin for the first time. A creates a directory in c:\recycler with the same name as V"s SID, and then sets Full Access for A and V on this directory. When V throws files in the recycle bin they will always retain their original permissions, and thus A will not be able to read their contents this way. However, since A has Full Access to the directory he/she will be able to delete all files in it. This is the first problem, A shouldn"t be able to delete files from V"s recycle bin.

The second problem is that if V throws an executable file into the recycle bin, A can delete it and then copy another executable file into the recycle bin and rename it to the same name as the original file had. That file could do anything A wants it to do. V might restore it and run it... after all, you probably trust what"s in your recycle bin.

Another possiblity (which I haven"t tried in practice, so I could be wrong) is for A to modify the INFO file in V"s recycle bin. Say that V has thrown a secret document into the recycle bin, and that A modifies the INFO file so it doesn"t point to the original location (which we suppose is located on a NTFS partition) but to a FAT partition. Then if V restores the file, it will loose its permissions, and V probably will never understand why it wasn"t restored but (to him/her) seems to be gone."

And according to Microsoft"s security bulletin on the matter,

"Under a very daunting set of conditions, a malicious user could create, delete or modify files in the Recycle Bin of another user who shared the machine. In most cases, the vulnerability would not allow the malicious user to read the files unless they already had read permission to do so.

The Windows NT Recycle Bin for a given user maps to a folder, whose name is based on the owner"s SID. The folder is created the first time the user deletes a file, and the owner is given sole permissions to it. However, if a malicious user could create the folder before the bona fide one were created, he or she could assign any desired permissions to it. This would allow him or her to create, modify or delete files in the Recycle Bin, but in most cases would not enable them to read files unless he or she already were able to.

There are several significant limitations that would make it difficult to
exploit this vulnerability:

• The malicious user would need to create the bogus Recycle
  Bin before the user"s bona fide one were created.
  
• The malicious user would need to share a machine with the
  other user. The vulnerability would only enable the malicious
  user to take action against the Recycle Bin on the particular
  machine, and the particular partition, that was attacked.
  
• The malicious user could add files to the Recycle Bin, but this
  vulnerability would not allow him or her to induce the other
  user to retrieve them.

VENDOR RESPONSE

Microsoft released a patch for Intel and Alpha, as well as a FAQ and Support Online article Q248399.

CREDITS
Discovered by Arne Vidstrom and Nubuo Miwa