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)
