Home page logo

bugtraq logo Bugtraq mailing list archives

"Recycle Bin Creation" Vulnerability in Windows NT / Windows 2000
From: arne.vidstrom () NTSECURITY NU (Arne Vidstrom)
Date: Tue, 1 Feb 2000 22:18:37 +0100

Hi all,

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.

Microsoft has released a patch and you can read more about it in their
Security Bulletin:


And you can also read about the exploit details in the security advisories
archive at ntsecurity.nu:


/Arne Vidstrom


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]