bugtraq - Re: Microsoft Windows Vista/2003/XP/2000 file management security issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Mar 2007 21:34:53 +0100
From: Paweł Goleń <p_golen@...onet.pl>
To: bugtraq@...urityfocus.com
Subject: Re: Microsoft Windows Vista/2003/XP/2000 file management security
 issues

3APA3A wrote:

> 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_.

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:p_golen@...onet.pl
UGVybCBTVUNLUw==