RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues
I appreciate you writing back.
But we'll have to agree to disagree. Your security scenarios are just bizarre.
It's a lot easier to hack people then going through all the interations you
suggest.
For one, I've been a sys admin for 20 years and NEVER created a private folder
under a public folder. Not in my Novell days, not in my Windows days. The only
time I've seen a private folder created under a public folder is the \Users
folder, and in that case, the users only have Read and List access to the
parent \Users folder, and then Full Control to their own folders.
I mean let's debate why users get Full Control to their own folders in the
first place. That's a common scenario (it's on nearly every network) and its
almost always too many permissions. Do I want my regular end-users changing
their folder's security permissions? No. Should any regular end-user have Full
Control to any share? No, for the same reason. These are valid, common,
security points that really do beg further discussion.
You're just making up crap up that isn't overly realistic in the world, then
going further to assume that a bonehead administrator compounds the problem by
making further insecure decisions.
You are essentially say, "If you misconfigure your system and make further
insecure choices, someone can hack you." Duh.
There's a reason why your "announcements" aren't making the news
media...because it isn't news.
With that said, you have something valid to say, but so far it just isn't a
"security vulnerability" that people need to be aware of.
You're a smart person, concentrate on issues that will really give us bang for
the buck discussions and issues.
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: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
Cc: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security
issues
Dear Roger A. Grimes,
--Friday, March 9, 2007, 7:31:54 AM, you wrote to 3APA3A@xxxxxxxxxxxxxxxx:
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
RAG> make up 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
RAG> set so 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
RAG> resources 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
RAG> I could easily defeat the problem you are suggesting by using
RAG> basic, 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 security
RAG> smarts.
Thanks.
RAG> Why not focus on more realistic scenarios with more real-world
RAG> use? There's plenty of them for us to focus on and to try and
RAG> 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 *CPA, CISSP, MCSE:
RAG> Security (2000/2003/MVP), CEH, yada...yada...
3APA3A. MCSE/MCT since Windows NT 4.0.
RAG> *email: roger_grimes@xxxxxxxxxxxxx or roger@xxxxxxxxxxxxxx *Author
RAG> 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@xxxxxxxxxxxxxxxx]
RAG> Sent: Thursday, March 08, 2007 2:59 PM
RAG> To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
RAG> Subject: Microsoft Windows Vista/2003/XP/2000 file management
RAG> security issues
RAG> This is an article I promised to publish after Windows
RAG> ReadDirectoryChangesW (CVE-2007-0843) [1] issue. It should
RAG> explain why you must never place secure data inside insecure directory.
RAG> Title: Microsoft Windows Vista/2003/XP/2000 file management
RAG> security 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
RAG> security weakness in few very common Windows management practices.
RAG> Neither of the 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
RAG> create something secured in insecure folder.
RAG> Scenario 1.1:
RAG> Bob wishes to create "Bob private data" folder in "Public"
RAG> folder to place few private files. "Public" has at least "Write"
RAG> permissions for "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/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)