I'm missing something here. In order for Alice to Take Ownership of Bob's private folder she would have to have Full Control in the parent Public folder or Bob's child folder, not just the Write/Modify permission. If Alice deletes Bob's folder (which she could do in some scenarios because she has the write/modify permission) and re-creates it, she becomes the Creator Owner and now Bob no longer has the ability to set permissions on it. If I take your strange assumptions, Bob could re-discover the newly created folder that Alice made, just like she did (I mean if you make up crap scenarios, why can't I), and do the same trick back to her. And Windows does have a umask-like function. It's called Creator Owner. It's a well known SID, and the default permissions for it can be set so that any granular permission you want can be set to be default. Vista does have symbolic links, and Windows has supported Junction Points (similar to symbolic links) since Windows 2000. The main difference is that Junction Points could only point to local resources and symbolic links can do remote resources as well. You've come up with some strange scenarios below, and in all cases I could easily defeat the problem you are suggesting by using basic, recommended, security settings. Why do you spend your time coming up with such weird scenarios to focus on? You're obviously a creative guy with some Windows security smarts. Why not focus on more realistic scenarios with more real-world use? There's plenty of them for us to focus on and to try and solve. Roger ***************************************************************** *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada... *email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx *Author of Professional Windows Desktop and Server Hardening (Wrox) *http://www.amazon.com/gp/product/0764599909 ***************************************************************** -----Original Message----- From: 3APA3A [mailto:3APA3A@xxxxxxxxxxxxxxxx] Sent: Thursday, March 08, 2007 2:59 PM To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx Subject: Microsoft Windows Vista/2003/XP/2000 file management security issues This is an article I promised to publish after Windows ReadDirectoryChangesW (CVE-2007-0843) [1] issue. It should explain why you must never place secure data inside insecure directory. Title: Microsoft Windows Vista/2003/XP/2000 file management security issues Author: 3APA3A, http://securityvulns.com/ Vendor: Microsoft (and potentially another vendors) Products: Microsoft Windows Vista/2003/XP/2000, Microsoft resource kit for Windows 2000 and different utilities. Access Vector: Local Type: multiple/complex (weak design, insecure file operations, etc) Original advisory: http://securityvulns.com/advisories/winfiles.asp Securityvulns.com news: http://security.nnov.ru/news/Microsoft/Windows/files.html 0. Intro This article contains a set of attack scenarios to demonstrate security weakness in few very common Windows management practices. Neither of the problem explained is critical, yet combined together they should force you to review your security practices. I can't even say "vulnerabilities" because there is no something you can call "vulnerability". It's just something you believe is secure and it's not. 1.1 Problem: inability to create secured file / folder in public one. Attack: folder hijack attack First, it's simply impossible with standard Windows interface to create something secured in insecure folder. Scenario 1.1: Bob wishes to create "Bob private data" folder in "Public" folder to place few private files. "Public" has at least "Write" permissions for "User" group. Bob: I Creates "Bob private data" folder II Sets permission for folder to only allow access to folder himself III Copies private files into folder Alice wants to get access to folder Bob created. She Ia Immediately after folder is created, deletes "Bob private data" folder and creates "Bob private data" folder again (or simply takes ownership under "Bob private data" folder if permissions allow). It makes Alice folder owner. IIa Immediately after Bob sets permissions, she grants herself full control under folder. She can do it as a folder owner. IIIa Reads Bob's private files, because files permissions are inherited from folder Alice can use "Spydir" (http://securityvulns.com/soft/) tool to monitor files access and automate this process. As you can see, [1] elevates this problem significantly. This is not new attack. Unix has "umask" command to protect administrators and users. Currently, Windows has nothing similar. CreateFile() API supports setting file ACL on file creation (just like open() allows to set mode on POSIX systems). ACL can be securely set only on newly created files. This raises a problem of secure file creation. 1.2 Problem: Inability to lock / securely change permissions of already created file Attack: pre-open file/directory attack. There are few classes of insecure file creation attack (attempt to open existing file), exploitable under Unix with hardlinks or symlinks. It's believed Windows is not vulnerable to this attacks because I. There is no symlinks under Windows. Symlink attacks are not possible. II. Security information in NTFS is not stored as a part of directory entry, it's a part of file data. Hard link attacks are not possible. III. File locks in Windows are mandatory. It means, if one application locks the file, another application can not open this file, if user doesn't have backup privileges. It mitigate different file-based attacks. There is at least one scenario, attacker can succeed without symbolic link: to steal data written to file created without check for file existence regardless of file locks and permissions. Attack description: if attacker can predict filename to be written, he can create file, open it and share this file for all types of access. Because locking and permissions are only checked on file open, attacker retain access to the file even if it's locked and it's permissions are changed to deny file access to attacker. Exploit (or useful tool): http://securityvulns.com/files/spyfile.c Opens file, shares it for different types of access and logs changes, keeping the file open. Compiled version is available from http://securityvulns.com/soft/ Scenario 1.2.1: Bob is now aware about folder hijack attack. He use xcopy /O /U /S to synchronize his files to newly created folder. xcopy /O copies security information (ownership and permissions) before writing data to file. Alice use "Spydir" to monitor newly created folders and files in Bob's directory. She use Spyfile to create spoofed files in target directory and waits for Bob to run xcopy. Now, she has full control under content of Bob's files despite the fact she has no permissions to access these files. In a same way directory content may be monitored by pre-opening directory. Scenario 1.2.2: Enterprise directory structure is replicated every day to another user-writable location in order to alow users to recover suddenly deleted or modified files. xcopy or robocopy (from resource kit) is used for replication. Attacker can hijack content of newly created files in newly created folders. Same problem may happen on archive extraction or backup restoration. Vulnerable applications: xcopy (from all Windows versions), robocopy (Windows 2000 Resource Kit), different archivers backup restoration utilities By default, xcopy warns user the file exists, unless /Y or /U key is specified. But I. /Y is always specified for replication II. /Y can be specified via COPYCMD environment variable. COPYCMD environment variable can be created in autoexec.bat file. Different situations are possible, where autoexec.bat is writable by attacker, if: - Default Windows 2000 permissions are used or applied with domain policy [2]. - One can try to re-create autoexec.bat using POSIX subsystem III. Neither xcopy nor other utilities warn user on existing directory. Pre-open directory attack will always succeed. As you can see, [1] again dramatically elevates this problem. 1.3 Problem: user can completely block access to the files Attack: open file deletion (including Windows file replication service DoS) If files is deleted while it's open, it still present in file system under it's old name until close. Any operation on this file (including attributes requests) fails, regardless of application rights and permissions (including backup ones). Exploit: use spyfile, delete file while it's spied. Now, without closing spyfile, attempt any operation on this file (e.g. try to find it's ownership). Scenario 1.3.1 Now Bob found an copy application to securely copy files. It deletes old file before creating new one. But it fails if Alice tries to spy on Bob files, because attempt to delete file succeeds, but file still present and is unmanageable. Scenario 1.3.2 Windows file replication service (FRS) is used to replicate data between 2 public DFS folders to distribute load. Folder has permissions: Everyone: Add & read Creator Owner: Full Control Thouse, Alice has no permissions to delete files created by Bob. Replicated folder is available as a share on 2 different servers: \\SERVER1\Share and \\SERVER2\Share. Bob is connected to \\SERVER1\Share. Alice uses "Spydir" to monitor files creation by Bob. Every time Bob creates new file on \\SERVER1\Share, Alice use spyfile to create file with same name on \\SERVER2\Share. It effectively leads to FRS collision. While trying to resolve collision, FRS fails to delete file created by Alice and Bob file is deleted (original file is moved to special hidden folder only accessible by administrator). Workaround: never try to use creator-owner based permissions in replicated folders. Again, [1] seriously escalates this problem. 2. Conclusion: It's simply impossible to securely create something in public folder. At least DoS conditions are always possible. Developers should not consider mandatory file locking as a security feature. Developers should care about secure file creation to store sensitive information. CREATE_NEW should always be used and ACL should be set with lpSecurityAttributes of CreateFile. No attempt to open existing file should be made. Never try to create secure folder in public one. If you are forced, disconnect all users before this operation. Never use replication, archive extraction or backup restore to user-accessible folder. Bob and Alice should finally marry. 3. Vendor: All timelines are same with [1]. [1]. Microsoft Windows ReadDirectoryChangesW information leak (CVE-2007-0843) http://security.nnov.ru/news/Microsoft/Windows/ReadDirector.html [2]. Windows 2000 system partition weak default permissions http://securityvulns.ru/news2205.html -- http://securityvulns.com/ /\_/\ { , . } |\ +--oQQo->{ ^ }<-----+ \ | ZARAZA U 3APA3A } You know my name - look up my number (The Beatles) +-------------o66o--+ / |/
