Discussion:
Microsoft Windows Vista/2003/XP/2000 file management security issues
(too old to reply)
3APA3A
2007-03-08 19:58:37 UTC
Permalink
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--+ /
|/
3APA3A
2007-03-09 12:09:26 UTC
Permalink
Dear Roger A. Grimes,

--Friday, March 9, 2007, 7:31:54 AM, you wrote to ***@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: ***@infoworld.com or ***@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:***@SECURITY.NNOV.RU]
RAG> Sent: Thursday, March 08, 2007 2:59 PM
RAG> To: ***@securityfocus.com; full-***@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
Roger A. Grimes
2007-03-09 15:49:13 UTC
Permalink
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: ***@infoworld.com or ***@banneretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
Cc: ***@securityfocus.com; full-***@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 ***@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
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: ***@infoworld.com or ***@banneretcs.com *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:***@SECURITY.NNOV.RU]
RAG> Sent: Thursday, March 08, 2007 2:59 PM
RAG> To: ***@securityfocus.com; full-***@lists.grok.org.uk
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/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted
Tim
2007-03-09 16:19:58 UTC
Permalink
Roger,
Post by Roger A. Grimes
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 find your assessment somewhat short-sighted. I have conducted code
reviews on several commercial apps which use C:\TEMP in very insecure
ways to store sensitive data. It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Roger A. Grimes
2007-03-09 17:42:13 UTC
Permalink
So, let me get this. An app storing sensitive data doesn't make its own
temp storage folders in a secure location, and instead relies upon one
of the few folders in Windows that all users have Full Control to, and
this is a Windows problem? In Linux, if an app uses \tmp, is that a
Linux issue?

Sounds like a developer issue to me.

Roger

-----Original Message-----
From: Tim [mailto:tim-***@sentinelchicken.org]
Sent: Friday, March 09, 2007 11:20 AM
To: Roger A. Grimes
Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
management security issues


I find your assessment somewhat short-sighted. I have conducted code
reviews on several commercial apps which use C:\TEMP in very insecure
ways to store sensitive data. It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim
Tim
2007-03-09 18:47:03 UTC
Permalink
Post by Roger A. Grimes
So, let me get this. An app storing sensitive data doesn't make its own
temp storage folders in a secure location, and instead relies upon one
of the few folders in Windows that all users have Full Control to, and
this is a Windows problem? In Linux, if an app uses \tmp, is that a
Linux issue?
Sounds like a developer issue to me.
No, I never said I blame Windows for a poorly written app such as this.
Don't jump to conclusions.

Many developers might think using predictable filenames in TEMP might be
ok, since Windows doesn't (yet) have issues related to symlink attacks.
However, ZARAZA has shown a few ways to exploit this lame practice
anyway, beyond just a DoS. That's all I'm saying.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Laundrup, Jens
2007-03-09 18:12:10 UTC
Permalink
Pardon me for maybe being a little naïve here, but the situation you state:

"I have conducted code reviews on several commercial apps which use C:\TEMP in very insecure ways to store sensitive data."

That would certainly seem to me that a programmer and the QA process failed. I struggle to see where Windows is to blame for that. I am no "Windows lover" but as a working security professional, I see as much poorly written code junking up Linux, Unix, Apples (yes we have them all) as I see with Windows, yet in those situations, will you blame the OS there too? I think it is time you take the bias you have, set it aside and look at the statement you made which was concise, accurate and factual, then point the blame where it belongs; at the code writers whose code you review!.

Cheers

Jens


-----Original Message-----
From: Tim [mailto:tim-***@sentinelchicken.org]
Sent: Friday, March 09, 2007 8:20 AM
To: Roger A. Grimes
Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

Roger,
Post by Roger A. Grimes
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 find your assessment somewhat short-sighted. It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim
Tim
2007-03-09 18:46:06 UTC
Permalink
Post by Laundrup, Jens
"I have conducted code reviews on several commercial apps which use C:\TEMP in very insecure ways to store sensitive data."
That would certainly seem to me that a programmer and the QA process
failed. I struggle to see where Windows is to blame for that. I am no
"Windows lover" but as a working security professional, I see as much
poorly written code junking up Linux, Unix, Apples (yes we have them
all) as I see with Windows, yet in those situations, will you blame the
OS there too? I think it is time you take the bias you have, set it
aside and look at the statement you made which was concise, accurate and
factual, then point the blame where it belongs; at the code writers
whose code you review!.
No, I never said I blame Windows for a poorly written app such as this.
Don't jump to conclusions.

Many developers might think using predictable filenames in TEMP might be
ok, since Windows doesn't (yet) have issues related to symlink attacks.
However, ZARAZA has shown a few ways to exploit this lame practice
anyway, beyond just a DoS. That's all I'm saying.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
3APA3A
2007-03-09 21:01:06 UTC
Permalink
Dear Laundrup, Jens,

C:\TEMP is not best example, but there are another.

Microsoft Word creates temporary file with predictable name in the same
directory with document. In the case of directory permissions like:

Users: Add & List
Creator Owner: Full control

(one user should not read documents created by another user)

it may creates security issue. And you may attempt to exploit it with
"preopen files".

Tim is right, it's attack vector, not vulnerability. You must have this
attack vector in mind during application development and administration.
I don't know if attack against e.g. Microsoft Word will work, it need to
be tested.

--Friday, March 9, 2007, 9:12:10 PM, you wrote to tim-***@sentinelchicken.org:

LJ> Pardon me for maybe being a little naïve here, but the situation you state:

LJ> "I have conducted code reviews on several commercial apps which
LJ> use C:\TEMP in very insecure ways to store sensitive data."

LJ> That would certainly seem to me that a programmer and the QA
LJ> process failed. I struggle to see where Windows is to blame for
LJ> that. I am no "Windows lover" but as a working security
LJ> professional, I see as much poorly written code junking up Linux,
LJ> Unix, Apples (yes we have them all) as I see with Windows, yet in
LJ> those situations, will you blame the OS there too? I think it is
LJ> time you take the bias you have, set it aside and look at the
LJ> statement you made which was concise, accurate and factual, then
LJ> point the blame where it belongs; at the code writers whose code you
LJ> review!.

LJ> Cheers

LJ> Jens


LJ> -----Original Message-----
LJ> From: Tim [mailto:tim-***@sentinelchicken.org]
LJ> Sent: Friday, March 09, 2007 8:20 AM
LJ> To: Roger A. Grimes
LJ> Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
LJ> Subject: Re: [Full-disclosure] Microsoft Windows
LJ> Vista/2003/XP/2000 file management security issues

LJ> Roger,
Post by Roger A. Grimes
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.
LJ> I find your assessment somewhat short-sighted. It seems some of these attacks would be
LJ> possible in those situations.

LJ> Sure, Windows is already pathetically insecure against an attackers
LJ> already on the local system, but this would be yet another attack
LJ> vector.

LJ> tim

LJ> _______________________________________________
LJ> Full-Disclosure - We believe in it.
LJ> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
LJ> Hosted and sponsored by Secunia - http://secunia.com/
--
~/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/
Thor (Hammer of God)
2007-03-10 16:28:27 UTC
Permalink
Apps utilizing temporary files should always use the TEMP or TMP environment
variables, not a hard-coded path. And by default, each user has their own
temp directory created (in XP/Server it is "\Documents and
Settings\username\Local Settings\temp" and in Vista it is
"\Users\username\AppData\Local\Temp") that only they have permissions to
(with SYSTEM and Administrators, of course). It's not like there is some
global "Full Control" temp directory created by default.

t



----- Original Message -----
From: "Roger A. Grimes" <***@banneretcs.com>
To: "Tim" <tim-***@sentinelchicken.org>
Cc: <***@securityfocus.com>; <full-***@lists.grok.org.uk>
Sent: Friday, March 09, 2007 9:42 AM
Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
management security issues


So, let me get this. An app storing sensitive data doesn't make its own
temp storage folders in a secure location, and instead relies upon one
of the few folders in Windows that all users have Full Control to, and
this is a Windows problem? In Linux, if an app uses \tmp, is that a
Linux issue?

Sounds like a developer issue to me.

Roger

-----Original Message-----
From: Tim [mailto:tim-***@sentinelchicken.org]
Sent: Friday, March 09, 2007 11:20 AM
To: Roger A. Grimes
Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
management security issues


I find your assessment somewhat short-sighted. I have conducted code
reviews on several commercial apps which use C:\TEMP in very insecure
ways to store sensitive data. It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim
Roger A. Grimes
2007-03-10 16:54:53 UTC
Permalink
Two things regarding this ongoing (civil) flame war:

1. I was wrong about most versions of Linux having the same inheritance
behavior as Windows. Dead wrong. And several people have wrote to
correct me. Thank you. The search for truth is more important than my
ego. <grin> Before I wrote that statement, I dropped into a VM of
knoppix that I had on my desktop to test. It's default umask is 000, and
thus the normal inheritance rules applied. After many people wrote, I
realized I used Foundstone's FSLive distro, which is a variation of
Knoppix, intentionally weakened for the classes we teach. It goes to
show that one sample finding does not a population make.

2. My bone of contention with the original poster, is not that he's an
idiot. He isn't. I'm objecting to his obscure insecurity scenario that
he uses to start the discussion (i.e. private folder created under a
public folder).

How many of you have intentionally created a private folder underneath a
public folder, where the public folder gave Modify/Change permissions to
the larger group?

It's got to be a small minority, and I'd question why even those people
did it.

I've been a sysadmin for 20 years and never done it. If someone was to
come to me and tell me they were going to do it, I'd caution them
against it. Not because of the poster's original concern, but because on
the onset it looks like bad security policy looking for trouble. I'd
recommend that a separate private folder be created every time.

Where I have seen public folders used with private folders underneath,
the larger group did not have Change/Modify permissions to the parent
public folder. They had Read and List, and couldn't modify other
people's child folders. That's very common.

The rest of his posting is a NTFS permissions 101 class. we've all been
taught that if you delete and re-create an object in Windows, even with
the same name, it isn't the same object. This applies to files, folders,
groups, users...every Windows object without exception. No surprise
there. We also know whoever creates the object is the Creator Owner and
gets Full Control. It's why Microsoft added the creator Owner SID so
that we could change the default behavior if we didn't like it. So, I
don't see the big "lesson" in his posting.

Now, before I get more people defending the original poster, I think his
exact same argument could be applied to a much more common scenario that
I see all the time, perhaps in 50% of all companies that I have audited.
It is where the Everyone group has Full Control to a public Share.
Unless you intend that anyone in your company can change permissions,
it's a bad thing to do. And don't start with that Windows makes that
the automatic default...that changed in XP. The default Share permission
is now Read, and the underlying NTFS permission (which wins in a
conflict), has never been Everyone Full Control by default in any
version of Windows since NT 4.0.

I'd rather the poster take the more popular problem I've mentioned in
the paragraph above and make the exact same argument, which is, if you
make a security configuration mistake (because all of these scenarios
are mistakes pure and simple), other users can use a timing attack and
deception to give themselves elevated access to your personal files.

It's still a valid lesson, but I'm not mentally tripping over a strange
start out assumption.

And in the end, the solution is an easy one:
1. Don't intentionally configure security weaknesses.
2. If you absolutely need to give users the ability to create private
folders under a public folder where users have Modify/Change or Full
Control permissions, you have four easy defenses:
a. Change default inheritance
b. Enable the Deny-Delete files and subfolders permission.
c. Change the Creator Owner SID's default permissions for that
folder.
d. Make them separate folders.
Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: ***@infoworld.com or ***@banneretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
3APA3A
2007-03-10 21:32:42 UTC
Permalink
Dear Thor (Hammer of God),

You are wrong at least for Windows XP/2003. There is a common temporary
directory

%WINDIR%\Temp

It's used as a %TEMP% if application is launched without local logon,
e.g. system service.

For example, services launched with LocalSystem account will have this
environment variables:

SystemRoot=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
USERPROFILE=C:\Documents and Settings\LocalService


You can find it's really used, because it's never empty. I see, e.g.
files related to different Intel drivers, VMWare, Microsoft .Net
framework, Exchange and Sharepoint.

Also, I remember I had problems with securing ABN AMRO Bank client
software installation, because it uses %WINDIR%\Temp for some reason.

And now is most exciting: Users have permission to create files in this
directory, that is pre-open attack is possible.

--Saturday, March 10, 2007, 7:28:27 PM, you wrote to ***@securityfocus.com:

THoG> Apps utilizing temporary files should always use the TEMP or TMP environment
THoG> variables, not a hard-coded path. And by default, each user has their own
THoG> temp directory created (in XP/Server it is "\Documents and
THoG> Settings\username\Local Settings\temp" and in Vista it is
THoG> "\Users\username\AppData\Local\Temp") that only they have permissions to
THoG> (with SYSTEM and Administrators, of course). It's not like there is some
THoG> global "Full Control" temp directory created by default.

THoG> t



THoG> ----- Original Message -----
THoG> From: "Roger A. Grimes" <***@banneretcs.com>
THoG> To: "Tim" <tim-***@sentinelchicken.org>
THoG> Cc: <***@securityfocus.com>;
THoG> <full-***@lists.grok.org.uk>
THoG> Sent: Friday, March 09, 2007 9:42 AM
THoG> Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
THoG> management security issues


THoG> So, let me get this. An app storing sensitive data doesn't make its own
THoG> temp storage folders in a secure location, and instead relies upon one
THoG> of the few folders in Windows that all users have Full Control to, and
THoG> this is a Windows problem? In Linux, if an app uses \tmp, is that a
THoG> Linux issue?

THoG> Sounds like a developer issue to me.

THoG> Roger

THoG> -----Original Message-----
THoG> From: Tim [mailto:tim-***@sentinelchicken.org]
THoG> Sent: Friday, March 09, 2007 11:20 AM
THoG> To: Roger A. Grimes
THoG> Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
THoG> Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
THoG> management security issues


THoG> I find your assessment somewhat short-sighted. I have conducted code
THoG> reviews on several commercial apps which use C:\TEMP in very insecure
THoG> ways to store sensitive data. It seems some of these attacks would be
THoG> possible in those situations.

THoG> Sure, Windows is already pathetically insecure against an attackers
THoG> already on the local system, but this would be yet another attack
THoG> vector.

THoG> tim
--
~/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/
Thor (Hammer of God)
2007-03-11 17:46:14 UTC
Permalink
2 things:

My point is what apps SHOULD do- use the "user" temp variable, not the
system temp variable if you want to easily have inherited, user-based
security. Not sure why your ABN AMRO client makes it files in
%WINDIR%\temp, but that's not necessary. It probably requires local admin
too, given that.

Secondly, I said there is not a "global Full Control" directory, and there
is not. The %WINDIR%\Temp directory has "special" permissions. For users,
it is only Traverse Folder/Execute File, Create Files/Write Data, and Create
Folders/ Append Data. Not List Folder/ Read Data, no read add tributes, not
write attributes, not delete, etc, etc.

And all subfolders in Temp inherit those permissions. I know it's used
extensively by system and admin installation, but that's not my point at
all. Someone chimed in about C:\temp and sensitive data, and blah blah, so
I simply stated that user variables usage for temp files mitigate that.
Also, there is no "Global Full Control" directory created by default temp
files and there's not. Sure you can create on if you want and use that
(which obviously someone did for C:\temp because it does not exist by
default) but that's more of Roger's point in that "if you do things
insecurely and without thinking, then someone can take advantage of that."
And I think he's right on that.

But as Mark said, the overall issue is interesting at some level,
particularly if you can leverage it even with limited permissions in
\windows\temp, though I also think many many things must go "wrong" first.
But, that being said, I've seen enough of your posts to know that you know
what you are doing, so I have respect for your work even though I may not
totally agree all the time.

t

----------------
Learn to secure your Microsoft installations with Tim Mullen's
"Microsoft Ninjitsu Black Belt Edition" at Blackhat Vegas. Registration
open now.
http://www.blackhat.com/html/bh-usa-07/train-bh-us-07-tm-ms-bbe.html





----- Original Message -----
From: "3APA3A" <***@SECURITY.NNOV.RU>
To: "Thor (Hammer of God)" <***@hammerofgod.com>
Cc: <***@securityfocus.com>; "Roger A. Grimes" <***@banneretcs.com>;
"Tim" <tim-***@sentinelchicken.org>;
<full-***@lists.grok.org.uk>
Sent: Saturday, March 10, 2007 2:32 PM
Subject: Re[2]: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
management security issues


Dear Thor (Hammer of God),

You are wrong at least for Windows XP/2003. There is a common temporary
directory

%WINDIR%\Temp

It's used as a %TEMP% if application is launched without local logon,
e.g. system service.

For example, services launched with LocalSystem account will have this
environment variables:

SystemRoot=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
USERPROFILE=C:\Documents and Settings\LocalService


You can find it's really used, because it's never empty. I see, e.g.
files related to different Intel drivers, VMWare, Microsoft .Net
framework, Exchange and Sharepoint.

Also, I remember I had problems with securing ABN AMRO Bank client
software installation, because it uses %WINDIR%\Temp for some reason.

And now is most exciting: Users have permission to create files in this
directory, that is pre-open attack is possible.

--Saturday, March 10, 2007, 7:28:27 PM, you wrote to
***@securityfocus.com:

THoG> Apps utilizing temporary files should always use the TEMP or TMP
environment
THoG> variables, not a hard-coded path. And by default, each user has their
own
THoG> temp directory created (in XP/Server it is "\Documents and
THoG> Settings\username\Local Settings\temp" and in Vista it is
THoG> "\Users\username\AppData\Local\Temp") that only they have permissions
to
THoG> (with SYSTEM and Administrators, of course). It's not like there is
some
THoG> global "Full Control" temp directory created by default.

THoG> t



THoG> ----- Original Message -----
THoG> From: "Roger A. Grimes" <***@banneretcs.com>
THoG> To: "Tim" <tim-***@sentinelchicken.org>
THoG> Cc: <***@securityfocus.com>;
THoG> <full-***@lists.grok.org.uk>
THoG> Sent: Friday, March 09, 2007 9:42 AM
THoG> Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000
file
THoG> management security issues


THoG> So, let me get this. An app storing sensitive data doesn't make its
own
THoG> temp storage folders in a secure location, and instead relies upon one
THoG> of the few folders in Windows that all users have Full Control to, and
THoG> this is a Windows problem? In Linux, if an app uses \tmp, is that a
THoG> Linux issue?

THoG> Sounds like a developer issue to me.

THoG> Roger

THoG> -----Original Message-----
THoG> From: Tim [mailto:tim-***@sentinelchicken.org]
THoG> Sent: Friday, March 09, 2007 11:20 AM
THoG> To: Roger A. Grimes
THoG> Cc: ***@securityfocus.com; full-***@lists.grok.org.uk
THoG> Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000
file
THoG> management security issues


THoG> I find your assessment somewhat short-sighted. I have conducted code
THoG> reviews on several commercial apps which use C:\TEMP in very insecure
THoG> ways to store sensitive data. It seems some of these attacks would be
THoG> possible in those situations.

THoG> Sure, Windows is already pathetically insecure against an attackers
THoG> already on the local system, but this would be yet another attack
THoG> vector.

THoG> tim
--
~/ZARAZA http://securityvulns.com/
ÝÍÈÀÊàì - ïî ìîðäå! (Ëåì)
Roger A. Grimes
2007-03-09 18:14:05 UTC
Permalink
But there is no difference in the treatment between this issue in Linux or Windows. In both systems, if I want to prevent attacks like this, I can do something ahead of time (i.e. umask or modify the Creator Owner SID, or inheritance). Only OpenBSD (and other BSD and hardened Linux's) do a better job by having a better default Umask. But in the typical Linux distro, I have to set the umask. He makes up a scenario of placing a secure folder insider of an insecure folder, and I'm somehow supposed to accept that as normal?

Mark, I respect you and your work greatly. I like a lot of 3APA3A's ideas and concerns....but they aren't in the realm of a real security concern. Real security concerns are when I can't do anything with the default OS to stop the weird attack they mention. In this case, there are plenty of things I can do. I don't have to buy software or be a security genius. I just have to not place a "secure" folder in an insecure folder.

Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: ***@infoworld.com or ***@banneretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: M. Burnett [mailto:***@xato.net]
Sent: Friday, March 09, 2007 12:44 PM
To: Roger A. Grimes; '3APA3A'; ***@securityfocus.com; full-***@lists.grok.org.uk
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues
Post by Roger A. Grimes
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.
Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability based on current scenarios because we really can't begin to imagine how these things might be exploited in future attacks. For example, the attack of deleting someone's folder and re-creating it before they set permissions sounds bizarre until someone makes a tool that does that automatically to all new folders. It changes everything when even the front desk secretary can pull off the attack.

And even if it would be lame for someone to set up a folder where this would be possible, people will still set up folders where this is possible. It's important for us to be aware of the risks of these configurations. And you have to admit, it is pretty amazing he found something we all missed for the last ten years, despite how simple it is.

Finally, I don't think 3APA3A is over hyping this issue beyond what it really is. He acknowledges that it isn't really a vulnerability and he's not submitting press releases to all the mainstream media. He gave Microsoft fair notice and awaited their decision and he's not screaming that everyone must abandon Windows. But he is informing the security community of something that we certainly should be aware of.


Mark Burnett
http://xato.net
Post by Roger A. Grimes
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
*****************************************************************
Security (2000/2003/MVP), CEH, yada...yada...
Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
http://winblogs.security-feed.com
Server Hardening, NTFS
-----Original Message-----
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
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
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
RAG> Junction Points (similar to symbolic links) since Windows 2000.
RAG> The main difference is that Junction Points could only point to
RAG> local 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
RAG> cases I could easily defeat the problem you are suggesting by
RAG> using 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> Security (2000/2003/MVP), CEH, yada...yada...
3APA3A. MCSE/MCT since Windows NT 4.0.
RAG> *Author of Professional Windows Desktop and Server Hardening
RAG> (Wrox)
RAG> *http://www.amazon.com/gp/product/0764599909
RAG> *****************************************************************
RAG> -----Original Message-----
RAG> Sent: Thursday, March 08, 2007 2:59 PM
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)
http://securityvulns.com/advisories/winfiles.asp
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> Bob wishes to create "Bob private data" folder in "Public"
RAG> folder to place few private files. "Public" has at least "Write"
RAG> I Creates "Bob private data" folder
RAG> II Sets permission for folder to only allow access to
RAG> folder 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,
RAG> if
one
RAG> application locks the file, another application can
RAG> 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
RAG> 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> 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> Bob is now aware about folder hijack attack. He use xcopy /O
RAG> /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> 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> 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> - 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
RAG> 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> Everyone: Add & read
RAG> Creator Owner: Full Control
RAG> Thouse, Alice has no permissions to delete files created by Bob.
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> 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> All timelines are same with [1].
http://passwords.security-feed.com
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
http://xato.net
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/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы.
(Лем)
M. Burnett
2007-03-09 17:43:50 UTC
Permalink
Post by Roger A. Grimes
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.
Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability
based on current scenarios because we really can't begin to imagine how
these things might be exploited in future attacks. For example, the attack
of deleting someone's folder and re-creating it before they set permissions
sounds bizarre until someone makes a tool that does that automatically to
all new folders. It changes everything when even the front desk secretary
can pull off the attack.

And even if it would be lame for someone to set up a folder where this would
be possible, people will still set up folders where this is possible. It's
important for us to be aware of the risks of these configurations. And you
have to admit, it is pretty amazing he found something we all missed for the
last ten years, despite how simple it is.

Finally, I don't think 3APA3A is over hyping this issue beyond what it
really is. He acknowledges that it isn't really a vulnerability and he's not
submitting press releases to all the mainstream media. He gave Microsoft
fair notice and awaited their decision and he's not screaming that everyone
must abandon Windows. But he is informing the security community of
something that we certainly should be aware of.


Mark Burnett
http://xato.net
Post by Roger A. Grimes
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...
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
http://winblogs.security-feed.com
Server Hardening, NTFS
-----Original Message-----
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
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
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> Security (2000/2003/MVP), CEH, yada...yada...
3APA3A. MCSE/MCT since Windows NT 4.0.
RAG> of Professional Windows Desktop and Server Hardening (Wrox)
RAG> *http://www.amazon.com/gp/product/0764599909
RAG> *****************************************************************
RAG> -----Original Message-----
RAG> Sent: Thursday, March 08, 2007 2:59 PM
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)
http://securityvulns.com/advisories/winfiles.asp
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> Bob wishes to create "Bob private data" folder in "Public"
RAG> folder to place few private files. "Public" has at least "Write"
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> 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> 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> 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> 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> - 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> Everyone: Add & read
RAG> Creator Owner: Full Control
RAG> Thouse, Alice has no permissions to delete files created by Bob.
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> 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> All timelines are same with [1].
http://passwords.security-feed.com
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
http://xato.net
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/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)
Roger A. Grimes
2007-03-09 18:01:19 UTC
Permalink
--This is getting boring. Let's take this offline, just between you and
me.

--You sound like many Linux/Unix guys I know who think they know Windows
security, but really don't. You're still acting like Windows security is
represented by Windows 95 without a firewall. You're mixing up your
security permissions, acting like you've never heard of the Creator
Owner SID, or the ability to change subfolder and file inheritance.
Either you don't know about them or you're purposefully ignoring them to
make your unlikely argument. Windows has incredibly security
granularity. You expect me to assume that the Windows administrator
makes bonehead configuration mistakes and I'm just supposed to accept
that as a Windows problem? You can argue that some Windows
administrators may not configure something correctly based upon
perceived risks...but I'm not blaming Windows for that.

--If make a public folder in Linux and give all users RWX, it
automatically flows down to the subfolders and objects, too. You can
configure Umask, but I can do exactly the same thing in Windows, using
the Creator Owner SID. So, you make additional change in Linux to make
it more secure, but I can't do the same in Windows...and that makes it a
Windows problem??

--See my other replies below.

Roger

*******************************************************************
*Roger A. Grimes, Senior Security Consultant
*Microsoft Application Consulting and Engineering (ACE) Services
*http://blogs.msdn.com/ace_team/default.aspx
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: ***@banneretcs.com or ***@microsoft.com
*******************************************************************



-----Original Message-----
From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
Sent: Friday, March 09, 2007 11:56 AM
To: Roger A. Grimes
Cc: full-***@lists.grok.org.uk
Subject: Re[4]: Microsoft Windows Vista/2003/XP/2000 file management
security issues

Nice. What about creating "Sales Reports" folder only head of Sales
department has access inside "Sales" folder?
--Poor security practice. Never done it. If it is for head of Sales
only, make it under the head of Sales' normal user folder. Easy. No
security problem.

There is no actual difference between "Change" and "Full Control"
permissions for NTFS.
--First, Change is a share permission, not an NTFS permission. Are you
talking Shares or NTFS permissions? In either case, there is a two major
differences between Change/Modify and Full Control. Those differences
are the ability to change permissions and taking ownership.

"Change" give you ability to delete and create objects. An ability to
delete some object and create it again give you a way to become object
owner, like if you have "Take ownership" individual permission. As an
owner you always have implicit "Change permissions" individual
permission. So, you have your "Full control" without having it. There
is simply nothing more to debate here. Ownership problem was debated for
ages.
--If you delete and re-create the object, it's a new object. Jeez! So,
the administrator intentionaly set up the folder or share so other
people could delete other people's objects, and this is a Windows
problem? Alice gets Full Control on her new object, not Bob's old
folder. If you want to prevent Bob from accidentally putting his
personal, private files into Alice's newly created folder...if that's a
concern, don't allow public users to have Change/Modify permissions to
subfolders in the public folder. In Windows you can easily choose what
objects inherit what permissions. If that is your concern, turn off
inheritance to subfolders and files. Microsoft put those options in the
Security tab GUI for a reason.

RAG> You're just making up crap up that isn't overly realistic in the
RAG> world, then going further to assume that a bonehead administrator
RAG> compounds the problem by making further insecure decisions.

RAG> You are essentially say, "If you misconfigure your system and make
RAG> further insecure choices, someone can hack you." Duh.

Who can tell me, creating "Sales reports" inside "Sales" is insecure
choice?
--Yes, absolutely.

RAG> There's a reason why your "announcements" aren't making the news

RAG> media...because it isn't news.

If I want to "make news media", I write article on Russian
cyberterrorism and it's connection with Ukraine, Germany and US. Not an
article on enterprise file management best security practices.
--At least that is a real problem.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
s***@lovebug.org
2007-03-09 21:30:51 UTC
Permalink
Excellent. I was wondering if one of you would notice the recipients list
could be edited or that there was another choice besides Reply to all.
Post by Roger A. Grimes
--This is getting boring. Let's take this offline, just between you and
me.
--You sound like many Linux/Unix guys I know who think they know Windows
security, but really don't. You're still acting like Windows security is
represented by Windows 95 without a firewall. You're mixing up your
security permissions, acting like you've never heard of the Creator
Owner SID, or the ability to change subfolder and file inheritance.
Either you don't know about them or you're purposefully ignoring them to
make your unlikely argument. Windows has incredibly security
granularity. You expect me to assume that the Windows administrator
makes bonehead configuration mistakes and I'm just supposed to accept
that as a Windows problem? You can argue that some Windows
administrators may not configure something correctly based upon
perceived risks...but I'm not blaming Windows for that.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Thor (Hammer of God)
2007-03-09 21:38:44 UTC
Permalink
Wouldn't properly using inheritance obviate the issue?

t



----- Original Message -----
From: "M. Burnett" <***@xato.net>
To: "'Roger A. Grimes'" <***@banneretcs.com>; "'3APA3A'"
<***@SECURITY.NNOV.RU>; <***@securityfocus.com>;
<full-***@lists.grok.org.uk>
Sent: Friday, March 09, 2007 9:43 AM
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
security issues
Post by Roger A. Grimes
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.
Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability
based on current scenarios because we really can't begin to imagine how
these things might be exploited in future attacks. For example, the attack
of deleting someone's folder and re-creating it before they set permissions
sounds bizarre until someone makes a tool that does that automatically to
all new folders. It changes everything when even the front desk secretary
can pull off the attack.

And even if it would be lame for someone to set up a folder where this would
be possible, people will still set up folders where this is possible. It's
important for us to be aware of the risks of these configurations. And you
have to admit, it is pretty amazing he found something we all missed for the
last ten years, despite how simple it is.

Finally, I don't think 3APA3A is over hyping this issue beyond what it
really is. He acknowledges that it isn't really a vulnerability and he's not
submitting press releases to all the mainstream media. He gave Microsoft
fair notice and awaited their decision and he's not screaming that everyone
must abandon Windows. But he is informing the security community of
something that we certainly should be aware of.


Mark Burnett
http://xato.net
Post by Roger A. Grimes
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...
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************
http://winblogs.security-feed.com
Server Hardening, NTFS
-----Original Message-----
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
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
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> Security (2000/2003/MVP), CEH, yada...yada...
3APA3A. MCSE/MCT since Windows NT 4.0.
RAG> of Professional Windows Desktop and Server Hardening (Wrox)
RAG> *http://www.amazon.com/gp/product/0764599909
RAG> *****************************************************************
RAG> -----Original Message-----
RAG> Sent: Thursday, March 08, 2007 2:59 PM
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)
http://securityvulns.com/advisories/winfiles.asp
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> Bob wishes to create "Bob private data" folder in "Public"
RAG> folder to place few private files. "Public" has at least "Write"
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> 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> 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> 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> 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> - 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> Everyone: Add & read
RAG> Creator Owner: Full Control
RAG> Thouse, Alice has no permissions to delete files created by Bob.
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> 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> All timelines are same with [1].
http://passwords.security-feed.com
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
http://xato.net
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/
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)
3APA3A
2007-03-09 12:40:04 UTC
Permalink
Dear M. Burnett,

--Friday, March 9, 2007, 7:12:31 AM, you wrote to ***@SECURITY.NNOV.RU:

MB> 3APA3A, I just wanted to say that is very clever research you have done.
MB> It's true that this does require some re-thinking of security practices, but
MB> I don't think it's accurate to say it's impossible to secure a private
MB> folder in a public one--I believe there is a way to do it securely.

Of cause, there is always a way to solve one specific problem. A
solution for problem #1 has problem #2. Solution for problem #2 has
problem #3.

MB> There are three basic attacks you described:
MB> 1. Attacker deletes a users' new folder then immediately re-creates it,
MB> establishing ownership of the folder
MB> 2. Attacker predicts filename, creates the file, then keeps it open for all
MB> access, retaining rights on the file
MB> 3. Attacker creates and deletes a file but keeps it open, denying any other
MB> access to that file.

And

4. By forcing irresolvable replication collision on DFS replicated
folder in conjunction with [3] attacker can delete newly created
files (and probably folders, I did no test) created by another user
even in case of permissions like this:

Users: Add & read
Creator Owner: full control (or something, doesn't matter).

MB> The last two attacks could be prevented by creating new files in a private
MB> folder that prevents others from creating files. However, item 1 could
MB> compromise the security of that folder when it is initially created. To
MB> prevent that situation you would need to make sure that, within a public
MB> directory, only the CREATOR OWNER can delete a folder, which I believe is
MB> the default setting.

MB> But, as you noticed, others can still delete that folder. There is a quirky
MB> thing in NTFS that allows users to delete subfolders and files without even
MB> having delete permissions on those files (see
MB> http://xato.net/bl/2007/01/04/pointless-permissions/). I think that if you
MB> set permissions on a folder that prevented users from deleting children, and
MB> only allowed CREATOR OWNER to delete new folders, when a user creates a new
MB> folder it will be secure, therefore protecting you from 2 and 3.

The problem with replicated folder has no relation to NTFS permissions.
It's not replication service itself, not user who deletes the file of
folder, because of collision. Attacker only forces collision situation.
This can not be fixed by NTFS permissions. "Add" NTFS permission is
only required to remove somebody's newly created file.

For replication service attacks is:

1. Victim creates Folder
2. Attacker creates Folder with same name on different replication mirror
and locks it.
3. Replication service detects collision and removes Folder
4. Attacker creates Folder again
5. Folder is replicated. Attacker is now folder owner.

MB> I haven't fully tested this to verify it, but I believe this would prevent
MB> all the scenarios you described, although a user could still prevent the
MB> initial folder creation if they could predict the filename.

As you can see, there is at least one situation where your assumption
is wrong, a case of DFS replication.

Of cause, it still can be solved somehow, but who can guarantee it's
impossible to find problem #5 in solution for problem #4?

MB> Nevertheless, these are still important issues that illustrate some of the
MB> confusion that the NTFS quirkiness leads to.



MB> Mark Burnett
MB> http://xato.net



MB> -----Original Message-----
MB> From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
MB> Sent: Thursday, March 08, 2007 12:59 PM
MB> Subject: Microsoft Windows Vista/2003/XP/2000 file management security
MB> issues
MB> To: ***@securityfocus.com; full-***@lists.grok.org.uk


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



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

MB> 0. Intro

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

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

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

MB> Scenario 1.1:

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

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

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

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

MB> Alice can use "Spydir" (http://securityvulns.com/soft/) tool to
MB> monitor files access and automate this process. As you can see, [1]
MB> elevates this problem significantly.

MB> This is not new attack. Unix has "umask" command to protect
MB> administrators and users. Currently, Windows has nothing similar.

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

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

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

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

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

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

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

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

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

MB> Scenario 1.2.1:

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

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

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

MB> Scenario 1.2.2:

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

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

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

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

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

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

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

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

MB> Scenario 1.3.1

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

MB> Scenario 1.3.2

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

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

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

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

MB> Again, [1] seriously escalates this problem.

MB> 2. Conclusion:

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

MB> 3. Vendor:

MB> All timelines are same with [1].


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

MB> http://winblogs.security-feeds.com
--
~/ZARAZA http://securityvulns.com/
Почтенные ископаемые! Жду от вас дальнейших писем. (Твен)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored
Roger A. Grimes
2007-03-09 04:31:54 UTC
Permalink
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: ***@infoworld.com or ***@banneretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
Sent: Thursday, March 08, 2007 2:59 PM
To: ***@securityfocus.com; full-***@lists.grok.org.uk
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--+ /
|/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Brent Stackhouse
2007-03-09 21:59:21 UTC
Permalink
Despite Roger's encouragement to move on from this topic (I guess Roger
can move on whenever he'd like, eh?), I appreciate the opportunity to
learn from the discussion. Thanks.

Brent Stackhouse, GSEC/GCIH
VP of Security
Solis Security, Inc.
Austin, Texas
www.solissecurity.com

-----Original Message-----
From: Roger A. Grimes [mailto:***@banneretcs.com]
Sent: Thursday, March 08, 2007 10:32 PM
To: 3APA3A; ***@securityfocus.com; full-***@lists.grok.org.uk
Subject: RE: Microsoft Windows Vista/2003/XP/2000 file management
security issues

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: ***@infoworld.com or ***@banneretcs.com *Author of
Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************


-----Original Message-----
From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
Sent: Thursday, March 08, 2007 2:59 PM
To: ***@securityfocus.com; full-***@lists.grok.org.uk
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--+ /
|/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
M. Burnett
2007-03-09 04:12:31 UTC
Permalink
3APA3A, I just wanted to say that is very clever research you have done.
It's true that this does require some re-thinking of security practices, but
I don't think it's accurate to say it's impossible to secure a private
folder in a public one--I believe there is a way to do it securely.

There are three basic attacks you described:
1. Attacker deletes a users' new folder then immediately re-creates it,
establishing ownership of the folder
2. Attacker predicts filename, creates the file, then keeps it open for all
access, retaining rights on the file
3. Attacker creates and deletes a file but keeps it open, denying any other
access to that file.

The last two attacks could be prevented by creating new files in a private
folder that prevents others from creating files. However, item 1 could
compromise the security of that folder when it is initially created. To
prevent that situation you would need to make sure that, within a public
directory, only the CREATOR OWNER can delete a folder, which I believe is
the default setting.

But, as you noticed, others can still delete that folder. There is a quirky
thing in NTFS that allows users to delete subfolders and files without even
having delete permissions on those files (see
http://xato.net/bl/2007/01/04/pointless-permissions/). I think that if you
set permissions on a folder that prevented users from deleting children, and
only allowed CREATOR OWNER to delete new folders, when a user creates a new
folder it will be secure, therefore protecting you from 2 and 3.

I haven't fully tested this to verify it, but I believe this would prevent
all the scenarios you described, although a user could still prevent the
initial folder creation if they could predict the filename.

Nevertheless, these are still important issues that illustrate some of the
confusion that the NTFS quirkiness leads to.



Mark Burnett
http://xato.net



-----Original Message-----
From: 3APA3A [mailto:***@SECURITY.NNOV.RU]
Sent: Thursday, March 08, 2007 12:59 PM
Subject: Microsoft Windows Vista/2003/XP/2000 file management security
issues
To: ***@securityfocus.com; full-***@lists.grok.org.uk


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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Steven M. Christey
2007-03-12 23:14:36 UTC
Permalink
I. There is no symlinks under Windows. Symlink attacks are not
possible.
I'm not a Windows expert, but... There have been some past
vulnerabilities where an attacker could upload a shortcut (.lnk) file
and access files outside of the intended directory. In cases of FTP
servers or mail clients, this makes symlink style attacks remotely
feasible. Some previously reported examples are
CVE-2004-2672/CVE-2005-0519/CVE-2005-0520 (argosoft), CVE-2005-2184
(eRoom), CVE-2005-0587 (Firefox), and CVE-2001-1386 (WFTPD).

So, issues *like* symlink vulnerabilities can happen on Windows - but
whether they're under-reported is unknown. Hard links, too
(CVE-2002-0725 for NT and CVE-2003-0844 for mod_gzip). Maybe there's
something about Windows API functions that make it more rare than in
the Unix world?

- Steve
3APA3A
2007-03-13 16:01:51 UTC
Permalink
Dear Steven M. Christey,
I. There is no symlinks under Windows. Symlink attacks are not
possible.
SMC> I'm not a Windows expert, but... There have been some past
SMC> vulnerabilities where an attacker could upload a shortcut (.lnk) file
SMC> and access files outside of the intended directory. In cases of FTP
SMC> servers or mail clients, this makes symlink style attacks remotely
SMC> feasible. Some previously reported examples are
SMC> CVE-2004-2672/CVE-2005-0519/CVE-2005-0520 (argosoft), CVE-2005-2184
SMC> (eRoom), CVE-2005-0587 (Firefox), and CVE-2001-1386 (WFTPD).
SMC> So, issues *like* symlink vulnerabilities can happen on Windows - but
SMC> whether they're under-reported is unknown.

These attacks are remote and have attack vector absolutely different
from Unix symlink attacks. Standard Windows files API doesn't handle
.lnk files, application must be specially written to support them.

Symlink attack is also possible against e.g. Cygwin-ported application.

But both cases are very special.

Pre-open file attack is general and exploits vulnerability in Windows
mandatory files locks. In standard case locking works:

Process 1: Opens file for writing with FILE_SHARE_NONE
Process 2: Attempts to open file for reading with
FILE_SHARE_WRITE|FILE_SHARE_READ|FILE_SHARE_DELETE and fails.

but in case of pre-open file locking fails:

Process 1: Opens file for reading with FILE_SHARE_WRITE|FILE_SHARE_READ|FILE_SHARE_DELETE
Process 2: Opens file for writing with FILE_SHARE_NONE and _succeeds_.

With valid mandatory locking implementation process 2 _must fail_.


SMC> Hard links, too
SMC> (CVE-2002-0725 for NT and CVE-2003-0844 for mod_gzip). Maybe there's
SMC> something about Windows API functions that make it more rare than in
SMC> the Unix world?

I didn't said there is no hard link, I said there is no hardlink-style
attack.

CVE-2002-0725 is an issue that hard link creation is not logged (the
rest of auditing results are expectable: file access is audited, but
name of hardlink is logged). It has no relation to hardlink attack.

CVE-2003-0844 describes real hard link attack, but it's only possible if
default "Strengthen default permissions of internal system objects"
policy is disabled. I see no vulnerability here, because it's enabled by
default and should never be disabled. If this policy is disabled, user
can create hardlink to the object he has no write access and it should
never happen. Otherwise it's _huge_ vulnerability by itself, having in
mind the fact user can create files in %WINDIR%/TEMP directory all
services use as a %TEMP%, it makes it possible to DoS and even
compromise the system without any mod_gzip.

SMC> - Steve
--
~/ZARAZA http://securityvulns.com/
Sir Isaac Newton discovered an apple falling to the ground (Mark Twain)
Daniel Hazelton
2007-03-13 17:29:39 UTC
Permalink
Post by 3APA3A
Dear Steven M. Christey,
--Tuesday, March 13, 2007, 2:14:36 AM, you wrote to
I. There is no symlinks under Windows. Symlink attacks are not
possible.
SMC> I'm not a Windows expert, but... There have been some past
SMC> vulnerabilities where an attacker could upload a shortcut (.lnk) file
SMC> and access files outside of the intended directory. In cases of FTP
SMC> servers or mail clients, this makes symlink style attacks remotely
SMC> feasible. Some previously reported examples are
SMC> CVE-2004-2672/CVE-2005-0519/CVE-2005-0520 (argosoft), CVE-2005-2184
SMC> (eRoom), CVE-2005-0587 (Firefox), and CVE-2001-1386 (WFTPD).
SMC> So, issues *like* symlink vulnerabilities can happen on Windows - but
SMC> whether they're under-reported is unknown.
These attacks are remote and have attack vector absolutely different
from Unix symlink attacks. Standard Windows files API doesn't handle
.lnk files, application must be specially written to support them.
Symlink attack is also possible against e.g. Cygwin-ported application.
I haven't used Vista at all, but from reading the MS documentation about the
new version of NTFS that it uses it appears that Unix style symlinks are
supported. (From what I can tell they've been possible since the start, just
not implemented)

So for any WIndows system that shares the new NTFS code with Vista this is a
valid vuln. Although I'm not positive about whether MS actually released
tools along with Vista to use this feature, I'm more than certain that it
does exist. (However, this may be a moot point. MS might still flag a
cross-reference like a Unix-style symlink as a filesystem error)

DRH
3APA3A
2007-03-13 20:38:02 UTC
Permalink
Dear Daniel Hazelton,

--Tuesday, March 13, 2007, 8:29:39 PM, you wrote to ***@securityfocus.com:


DH> I haven't used Vista at all, but from reading the MS documentation about the
DH> new version of NTFS that it uses it appears that Unix style symlinks are
DH> supported. (From what I can tell they've been possible since the start, just
DH> not implemented)

DH> So for any WIndows system that shares the new NTFS code with Vista this is a
DH> valid vuln. Although I'm not positive about whether MS actually released
DH> tools along with Vista to use this feature, I'm more than certain that it
DH> does exist. (However, this may be a moot point. MS might still flag a
DH> cross-reference like a Unix-style symlink as a filesystem error)

Yes, Vista supports Unix-style symlinks and there is "mklink". By
default, only member of administrators group can create ones and this
policy should never be changed. So, again, there is no symlink
vulnerability in it's classic way in default configuration.

Only if you change symlink policy, you get security hole. In terms of
Unix, you'll get system with commonly used /tmp and without mkstemp()
ever used.
--
~/ZARAZA http://securityvulns.com/
Paweł Goleń
2007-03-13 20:34:53 UTC
Permalink
Post by 3APA3A
Pre-open file attack is general and exploits vulnerability in Windows
Process 1: Opens file for writing with FILE_SHARE_NONE
Process 2: Attempts to open file for reading with
FILE_SHARE_WRITE|FILE_SHARE_READ|FILE_SHARE_DELETE and fails.
Process 1: Opens file for reading with FILE_SHARE_WRITE|FILE_SHARE_READ|FILE_SHARE_DELETE
Process 2: Opens file for writing with FILE_SHARE_NONE and _succeeds_.
With valid mandatory locking implementation process 2 _must fail_.
3APA3A, from one hand you are right this may be considered to be
vulnerability in Windows mandatory file locks. But I'm not sure if file
locks in Windows are mandatory. I've never considered "share modes" to
be security feature. You are right that there are bugs related to this
implementation, but... (and here comes my "other hand").

In all scenarios you made assumption that attacker opens file (after all
you used term "preopen") first with FILE_SHARE_WRITE, FILE_SHARE_READ
and FILE_SHARE_DELETE. Subsequent open operation on that opened file
will succeeds, because they don't violates rules placed by first open
operation (sharing for all operations is allowed). So if I want to
create file AND not share it with another processess I should _create_
this file, not _open_ file created by someone else. Of course checking
if file exists is not good solution, because my process is not the only
process in the system and after checking and before creating my file
someone may create this file for me :). In order to be sure I'm creating
not opening file I would probably used CREATE_NEW as value for
dwCreationDisposition attribute AND FILE_SHARE_NONE to prevent others
processess to open my file. So at this moment I see two targets:
- successfuly open file that is already opened with FILE_SHARE_NONE flag,
- create file in that way, that creating file with the same name with
CREATE_NEW will succeed.

Am I correct or I'm missing something?

And one question - which flag for dwCreationDisposition is used for
example by Microsoft World during creating temporary files.
--
Paweł Goleń
mailto:***@ks.onet.pl
UGVybCBTVUNLUw==
3APA3A
2007-03-13 23:08:00 UTC
Permalink
Dear Paweł Goleń,
Post by 3APA3A
Process 1: Opens file for reading with
FILE_SHARE_WRITE|FILE_SHARE_READ|FILE_SHARE_DELETE
Process 2: Opens file for writing with FILE_SHARE_NONE and _succeeds_.
With valid mandatory locking implementation process 2 _must fail_.
PG> 3APA3A, from one hand you are right this may be considered to be
PG> vulnerability in Windows mandatory file locks. But I'm not sure if file
PG> locks in Windows are mandatory. I've never considered "share modes" to
PG> be security feature.

It was advised in original article.

PG> In order to be sure I'm creating not opening file I would probably
PG> used CREATE_NEW as value for dwCreationDisposition attribute AND
PG> FILE_SHARE_NONE to prevent others processess to open my file.

...

PG> Am I correct or I'm missing something?

You are right, and again it was advised in article.

You've only missed the fact, sometimes you need to create a file with
given name. The examples were demonstrated - file copy operation,
archive extraction, restore from backup, file replications and creation
of any persistent file (e.g. new document). And you get a problem - what
to do with existing file, you can not simply create new one.

At my opinion, if CREATE_NEW fails because file exists and user asks to
overwrite file, application should try to remove existing file and
re-create it with CREATE_NEW and fail, if second attempt with CREATE_NEW
fails. But: ALL TESTED APPLICATIONS FAILED to act like this. It's true
even for application you may expect to operate in secure way, because
they restore original file permissions and may be used to copy secret
information.

Namely:

xcopy (standard utility) with /Y opens existing file without attempt
to delete it.
robocopy (from resource kit) opens existing file
ntbackup (if "replace file" option is on during restore) opens existing
file
rar opens existing file

PG> And one question - which flag for dwCreationDisposition is used for
PG> example by Microsoft World during creating temporary files.

According to tests I recently made, Word correctly behaves with both
original file (it doesn't edit original file, but renames it, creates
new one and copies content) and temporary file (also new file is
created). It may be slow, but it's safe :) It may be possible to catch
race condition between old file is renamed and new one is created, but
it's a bit harder to test.
--
~/ZARAZA http://securityvulns.com/
Richard Huxton
2007-03-13 16:21:51 UTC
Permalink
I. There is no symlinks under Windows. Symlink attacks are not
possible.
There's something similar on NTFS:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx
http://en.wikipedia.org/wiki/NTFS_symbolic_link

Only reason I know is because I remember the Win32 porters of PostgreSQL
looking around for symlinks on Windows.
--
Richard Huxton
Archonet Ltd
Continue reading on narkive:
Loading...