RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
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=20
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes@infoworld.com or roger@banneretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
-----Original Message-----
From: 3APA3A [mailto:3APA3A@SECURITY.NNOV.RU]=20
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
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@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=20
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=20
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=20
RAG> Points (similar to symbolic links) since Windows 2000. The main=20
RAG> difference is that Junction Points could only point to local=20
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=20
RAG> I could easily defeat the problem you are suggesting by using=20
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 =20
RAG> smarts.
Thanks.
RAG> Why not focus on more realistic scenarios with more real-world=20
RAG> use? There's plenty of them for us to focus on and to try and=20
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:=20
RAG> 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 *Author=20
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@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=20
RAG> security issues
RAG> This is an article I promised to publish after =
Windows
RAG> ReadDirectoryChangesW (CVE-2007-0843) [1] issue. It should=20
RAG> explain why you must never place secure data inside insecure =
directory.
RAG> Title: Microsoft Windows Vista/2003/XP/2000 file management=20
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=20
RAG> security weakness in few very common Windows management practices.=20
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=20
RAG> create something secured in insecure folder.
RAG> Scenario 1.1:
RAG> Bob wishes to create "Bob private data" folder in "Public"=20
RAG> folder to place few private files. "Public" has at least "Write"=20
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=20
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"=20
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.
=20
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.
=20
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.
=20
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=20
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/
=EE=CF =D7=C5=C4=D8 =CB=CF=CD=D5 =D5=C7=CF=C4=CE=CF =CD=CF=C7=D5=D4 =
=D0=D2=C9=CA=D4=C9 =D7 =C7=CF=CC=CF=D7=D5 =D1=CA=C3=C1, =D0=D1=D4=CB=C9 =
=C9 =C5=D0=C9=D3=CB=CF=D0=D9. (=EC=C5=CD)
討論串 (同標題文章)
完整討論串 (本文為第 1 之 3 篇)：