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@xxxxxxxxxxxxxxxxx:
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)