COMMAND

    Recycle bin

SYSTEMS AFFECTED

    WinNT, 2000

PROBLEM

    Arne Vidstrom found following.   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 Nobuo Miwa and Arne Vidstrom.

    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 (mot tested in practice, so it 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.

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

        http://ntsecurity.nu/advisories/a14.shtml

    Nobuo  Miwa  posted  following.   He  made  a small program.  This
    makes a lots of folders under Recycler folder.  ANY users can make
    folders  under  Recycler   folder.   Like   this....   When   some
    user("user1")'s SID is

        S-1-5-21-823518204-813497703-1708537768-1004,

    program will make

        S-1-5-21-823518204-813497703-1708537768-1001
        S-1-5-21-823518204-813497703-1708537768-1002
        S-1-5-21-823518204-813497703-1708537768-1003
        ...
        ...
        S-1-5-21-823518204-813497703-1708537768-1199
        S-1-5-21-823518204-813497703-1708537768-1200

    In this case its parameter is "RecyclerSnooper.exe 200 C".   After
    that another user("user2",  SID=...1006) throw garbage  away FIRST
    time, user1  can read  it.   Yeah, user1  can read  another user's
    garbages in  case another  user didn't  throw garbage  yet.   It's
    minor problem.

    You can download and test from

        http://www.lac.co.jp/security/test/files/RecyclerSnooper.exe

    This could be available on WinNT and Win2K.

SOLUTION

    Patch availability:

        - Intel: http://www.microsoft.com/downloads/release.asp?ReleaseID=17606
        - Alpha: http://www.microsoft.com/downloads/release.asp?ReleaseID=17607

    NOTE: This patch  only needs to  be applied to  Windows NT systems
    using  NTFS  file  volumes.   The  vulnerability  is  moot for FAT
    volumes, as FAT  provides no per-user  data separation by  design.
    See the FAQ for more information.