bugtraq - Re[2]: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <699038966.20070313190151@SECURITY.NNOV.RU>
Date: Tue, 13 Mar 2007 19:01:51 +0300
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: "Steven M. Christey" <coley@...re.org>
Cc: bugtraq@...urityfocus.com
Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

Dear Steven M. Christey,

--Tuesday, March 13, 2007, 2:14:36 AM, you wrote to bugtraq@...urityfocus.com:

SMC> 3APA3A said:

>>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)