Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Microsoft Windows Vista/2003/XP/2000 file management security issues
From: 3APA3A <3APA3A () SECURITY NNOV RU>
Date: Fri, 9 Mar 2007 15:09:26 +0300

Dear Roger A. Grimes,

--Friday, March 9, 2007, 7:31:54 AM, you wrote to 3APA3A () SECURITY NNOV RU:

RAG> If Alice deletes Bob's folder (which she could do in some scenarios
RAG> because she has the write/modify permission) and re-creates it, she
RAG> becomes  the Creator Owner and now Bob no longer has the ability to
RAG> set permissions on it.

As a folder owner Alice can give any permissions to Bob she wants.

RAG> If I take your strange assumptions, Bob could re-discover the newly
RAG> created folder that Alice made, just like she did (I mean if you make up
RAG> crap scenarios, why can't I), and do the same trick back to her.

He can, if he knows he must.

RAG> And Windows does have a umask-like function. It's called Creator Owner.
RAG> It's a well known SID, and the default permissions for it can be set so
RAG> that any granular permission you want can be set to be default. 

I  see  nothing  similar  between Creator Owner and umask. BTW, the same
article  explains  why  Creator  Owner  is not 100% solution and why you
should not rely on Creator Owner in case of DFS replication.

RAG> Vista does have symbolic links, and Windows has supported Junction
RAG> Points (similar to symbolic links) since Windows 2000. The main
RAG> difference is that Junction Points could only point to local resources
RAG> and symbolic links can do remote resources as well.

Junction  points are very close to Unix mounts, I see no any likeness to
symbolic  links.  Junctions  points  (and  by default, symbolic links in
Vista)  can  only  be  created  by  administrators,  it prevents symlink
attack. And it's right choice.

RAG> You've come up with some strange scenarios below, and in all cases I
RAG> could easily defeat the problem you are suggesting by using basic,
RAG> recommended, security settings. 


"You never know what is enough unless you know more than enough."
                                                    William Blake

It's  quite  hard  to defeat the threat without knowing it. I'm disagree
with  you about "recommended security settings". I never saw "disconnect
all  users and close access to the share" or "check you are still folder
owner before copy the data" in instructions on how to create file/folder
with restricted access inside public one. Or "xcopy /O doesn't guarantee
file  can  not  be  accessed  during  copy operation" or "Do not rely on
Creator Owner in case of replication".

RAG> Why  do  you spend your time coming up with such weird scenarios to
RAG> focus  on?

Roger,  have  you  ever  used  robocopy  or  xcopy  /O? I'm not security
columnist,  I  am  system  administrator/engineer.  For  last 10 years I
develop   and   implement  a  lot  of  corporate  directory  structures,
replications,  and  backup/restore  policies  for  many  very  different
organizations.  I explain mistakes I can personally make and sometimes I
personally  did (mixing secure and insecure data, implementing automatic
replication  to  unprotected folders, implementing data restore policies
where  user  can  ask  system  administrator  to  restore some directory
structure  to  user accessible folder, etc). May be I'm only dumb person
who  does  mistakes  like  that,  most probably not. I call it "properly
placed rakes to step on".

RAG> You're  obviously  a  creative  guy  with  some Windows
RAG> security  smarts.

Thanks.

RAG> Why  not  focus on more realistic scenarios with
RAG> more  real-world use? There's plenty of them for us to focus on and
RAG> to try and solve.

Roger,  of  cause  next  time  I  should  concentrate on a single-packet
exploitable overflow in IPv6 stack to interest InfoWorld readers. I will
not,  because  it's  nothing interesting for me in searching yet another
buffer  overflow.  Let  another  creative  guys  who are professional in
vulnerability  researching  to  dig it. They have tools, time and money.
For me, most valuable vulnerability is one simple enough to be exploited
with notepad, because it can be noted by everyone, but was unnoticed for
10 years.

RAG> Roger

RAG> *****************************************************************
RAG> *Roger A. Grimes, InfoWorld, Security Columnist 
RAG> *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...

3APA3A. MCSE/MCT since Windows NT 4.0.

RAG> *email: roger_grimes () infoworld com or roger () banneretcs com
RAG> *Author of Professional Windows Desktop and Server Hardening (Wrox)
RAG> *http://www.amazon.com/gp/product/0764599909
RAG> *****************************************************************


RAG> -----Original Message-----
RAG> From: 3APA3A [mailto:3APA3A () SECURITY NNOV RU] 
RAG> Sent: Thursday, March 08, 2007 2:59 PM
RAG> To: bugtraq () securityfocus com; full-disclosure () lists grok org uk
RAG> Subject: Microsoft Windows Vista/2003/XP/2000 file management security
RAG> issues


RAG> This   is   an   article   I   promised   to   publish   after  Windows
RAG> ReadDirectoryChangesW  (CVE-2007-0843)  [1] issue. It should explain why
RAG> you must never place secure data inside insecure directory.



RAG> Title: Microsoft Windows Vista/2003/XP/2000 file management security
RAG> issues
RAG> Author: 3APA3A, http://securityvulns.com/
RAG> Vendor: Microsoft (and potentially another vendors)
RAG> Products:  Microsoft  Windows Vista/2003/XP/2000, Microsoft resource kit
RAG>            for Windows 2000 and different utilities.
RAG> Access Vector: Local
RAG> Type: multiple/complex (weak design, insecure file operations, etc)
RAG> Original advisory: http://securityvulns.com/advisories/winfiles.asp
RAG> Securityvulns.com news:
RAG> http://security.nnov.ru/news/Microsoft/Windows/files.html

RAG> 0. Intro

RAG> This  article contains a set of attack scenarios to demonstrate security
RAG> weakness in few very common Windows management practices. Neither of the
RAG> problem  explained  is critical, yet combined together they should force
RAG> you   to   review   your   security   practices.   I   can't  even  say
RAG> "vulnerabilities"   because   there   is   no  something  you can  call
RAG> "vulnerability". It's just something you believe is secure and it's not.

RAG> 1.1 Problem: inability to create secured file / folder in public one.
RAG>     Attack: folder hijack attack

RAG> First,  it's simply impossible with standard Windows interface to create
RAG> something secured in insecure folder.

RAG>  Scenario  1.1:

RAG>  Bob  wishes  to  create "Bob private data" folder in "Public" folder to
RAG> place  few private files. "Public" has at least "Write" permissions for
RAG> "User" group. Bob:

RAG>      I   Creates "Bob private data" folder
RAG>      II  Sets permission for folder to only allow access to folder
RAG> himself
RAG>      III Copies private files into folder

RAG>   Alice wants to get access to folder Bob created. She

RAG>      Ia  Immediately  after  folder  is  created,  deletes "Bob private
RAG>          data"  folder  and creates "Bob private data" folder again (or
RAG>          simply  takes  ownership  under  "Bob  private data" folder if
RAG>          permissions allow). It makes Alice folder owner.
RAG>      IIa Immediately  after  Bob  sets permissions, she grants herself
RAG>          full control under folder. She can do it as a folder owner.
RAG>      IIIa  Reads  Bob's  private  files,  because  files permissions are
RAG>          inherited from folder

RAG>   Alice   can  use  "Spydir" 
RAG> (http://securityvulns.com/soft/)  tool  to
RAG>   monitor  files  access  and automate this process. As you can see, [1]
RAG>   elevates this problem significantly.
     
RAG>   This   is  not  new  attack.  Unix  has  "umask"  command  to  protect
RAG>   administrators and users. Currently, Windows has nothing similar.

RAG>   CreateFile() API supports setting file ACL on file creation (just like
RAG>   open()  allows  to set mode on POSIX systems). ACL can be securely set
RAG>   only  on  newly  created  files.  This raises a problem of secure file
RAG>   creation.

RAG> 1.2  Problem: Inability to lock / securely change permissions of already
RAG>      created file
RAG>      Attack: pre-open file/directory attack.

RAG>   There  are  few  classes  of insecure file creation attack (attempt to
RAG>   open   existing  file),  exploitable  under  Unix  with  hardlinks  or
RAG>   symlinks.  It's  believed  Windows  is  not vulnerable to this attacks
RAG>   because

RAG>     I.  There  is  no  symlinks  under Windows. Symlink attacks are not
RAG>         possible.
RAG>     II. Security  information  in  NTFS  is  not  stored  as  a part of
RAG>         directory entry, it's a part of file data. Hard link attacks are
RAG>         not possible.
RAG>     III. File  locks  in  Windows  are  mandatory.  It  means,  if  one
RAG>          application  locks  the file, another application can not open
RAG>          this  file, if user doesn't have backup privileges. It mitigate
RAG>          different file-based attacks.

RAG>   There  is at least one scenario, attacker can succeed without symbolic
RAG>   link:  to  steal  data  written to file created without check for file
RAG>   existence regardless of file locks and permissions.

RAG>   Attack description: if attacker can predict filename to be written, he
RAG>   can  create file, open it and share this file for all types of access.
RAG>   Because  locking  and  permissions  are  only  checked  on  file open,
RAG>   attacker  retain  access  to  the  file  even  if it's locked and it's
RAG>   permissions are changed to deny file access to attacker.

RAG>   Exploit (or useful tool):
RAG> http://securityvulns.com/files/spyfile.c

RAG>   Opens  file, shares it for different types of access and logs changes,
RAG>   keeping the file open.

RAG>   Compiled version is available from http://securityvulns.com/soft/

RAG>   Scenario 1.2.1:

RAG>    Bob is now aware about folder hijack attack. He use xcopy /O /U /S to
RAG>    synchronize  his  files  to  newly  created  folder.  xcopy /O copies
RAG>    security  information (ownership and permissions) before writing data
RAG>    to file.

RAG>    Alice  use  "Spydir"  to  monitor  newly created folders and files in
RAG>    Bob's  directory.  She  use Spyfile to create spoofed files in target
RAG>    directory  and  waits for Bob to run xcopy. Now, she has full control
RAG>    under  content of Bob's files despite the fact she has no permissions
RAG>    to access these files.

RAG>    In  a  same  way  directory  content  may be monitored by pre-opening
RAG>    directory.

RAG>   Scenario 1.2.2:

RAG>    Enterprise  directory  structure  is  replicated every day to another
RAG>    user-writable  location  in  order  to alow users to recover suddenly
RAG>    deleted  or  modified files. xcopy or robocopy (from resource kit) is
RAG>    used  for  replication.  Attacker can hijack content of newly created
RAG>    files in newly created folders.

RAG>   Same problem may happen on archive extraction or backup restoration.

RAG>   Vulnerable  applications:
RAG>     xcopy (from all Windows versions),
RAG>     robocopy (Windows  2000  Resource Kit),
RAG>     different archivers
RAG>     backup restoration utilities

RAG>   By  default,  xcopy warns user the file exists, unless /Y or /U key is
RAG>   specified.  But
RAG>     I.  /Y  is  always  specified  for replication
RAG>     II. /Y  can  be specified via COPYCMD environment variable. COPYCMD
RAG>     environment    variable   can  be  created  in  autoexec.bat  file.
RAG>     Different situations are possible, where autoexec.bat is writable by
RAG>     attacker, if:
RAG>      - Default Windows 2000 permissions are used or applied with domain
RAG>      policy [2].
RAG>      - One can try to re-create autoexec.bat using POSIX subsystem
RAG>     III.  Neither  xcopy  nor  other  utilities  warn user on existing
RAG>     directory. Pre-open directory attack will always succeed.

RAG>   As you can see, [1] again dramatically elevates this problem.

RAG> 1.3 Problem: user can completely block access to the files
RAG>     Attack: open file deletion
RAG>     (including Windows file replication service DoS)

RAG>     If files is deleted while it's open, it still present in file system
RAG>     under  it's  old  name  until  close.  Any  operation  on this file
RAG>     (including  attributes  requests)  fails,  regardless of application
RAG>     rights and permissions (including backup ones).

RAG>     Exploit:  use  spyfile,  delete  file while it's spied. Now, without
RAG>     closing  spyfile,  attempt  any  operation on this file (e.g. try to
RAG>     find it's ownership).

RAG>     Scenario 1.3.1

RAG>     Now Bob found an copy application to securely copy files. It deletes
RAG>     old file before creating new one. But it fails if Alice tries to spy
RAG>     on  Bob  files,  because  attempt  to delete file succeeds, but file
RAG>     still present and is unmanageable.

RAG>     Scenario 1.3.2

RAG>     Windows  file  replication  service  (FRS) is used to replicate data
RAG>     between  2  public  DFS  folders  to  distribute  load.  Folder  has
RAG>     permissions:
RAG>      Everyone: Add & read
RAG>      Creator Owner: Full Control
RAG>     Thouse, Alice has no permissions to delete files created by Bob.

RAG>     Replicated  folder  is  available as a share on 2 different servers:
RAG>     \\SERVER1\Share    and    \\SERVER2\Share.    Bob    is   connected
RAG>     to \\SERVER1\Share.

RAG>     Alice uses "Spydir" to monitor files creation by Bob. Every time Bob
RAG>     creates  new  file  on  \\SERVER1\Share, Alice use spyfile to create
RAG>     file  with same name on \\SERVER2\Share. It effectively leads to FRS
RAG>     collision.  While  trying  to resolve collision, FRS fails to delete
RAG>     file  created  by  Alice  and  Bob file is deleted (original file is
RAG>     moved to special hidden folder only accessible by administrator).

RAG>     Workaround:  never  try  to  use  creator-owner based permissions in
RAG>     replicated folders.

RAG>     Again, [1] seriously escalates this problem.
    
RAG> 2. Conclusion:

RAG>   It's  simply impossible to securely create something in public folder.
RAG>   At least DoS conditions are always possible.
RAG>   Developers should  not  consider mandatory file locking as a security
RAG>   feature.
RAG>   Developers  should  care about secure file creation to store sensitive
RAG>   information.  CREATE_NEW  should  always be used and ACL should be set
RAG>   with  lpSecurityAttributes  of CreateFile. No attempt to open existing
RAG>   file should be made.
RAG>   Never  try  to  create secure folder in public one. If you are forced,
RAG>   disconnect     all   users   before   this   operation.
RAG>   Never  use  replication,  archive  extraction  or  backup  restore  to
RAG>   user-accessible folder.
RAG>   Bob and Alice should finally marry.
    
RAG> 3. Vendor:

RAG>   All timelines are same with [1].


RAG> [1]. Microsoft Windows ReadDirectoryChangesW information leak
RAG> (CVE-2007-0843)
RAG> http://security.nnov.ru/news/Microsoft/Windows/ReadDirector.html
RAG> [2]. Windows 2000 system partition weak default permissions
RAG> http://securityvulns.ru/news2205.html

RAG> --
RAG> http://securityvulns.com/
RAG>          /\_/\
RAG>         { , . }     |\
RAG> +--oQQo->{ ^ }<-----+ \
RAG> |  ZARAZA  U  3APA3A   } You know my name - look up my number (The
RAG> Beatles)
RAG> +-------------o66o--+ /
RAG>                     |/



-- 
~/ZARAZA http://securityvulns.com/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

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