<span style="font-style: italic;"><span style="font-style: italic;"></span></span>Hi,<br><br>You told that as a workaround that we should never allow "creation of more secure folder in less secure ones."<br>
<br>
I agree but, as i see.., that means that also allowing the "Bypass traverse checking" policy is also a bad idea.<br><br>Anyway, there are several scenarios where we could not protect us against that threat easily, like for example a shared environment with terminal server/citrix where all our stored documents can be stolen.
<br>In that case, only a software restriction policy will protect us.<br><br>regards,<br><br>Andres Tarasco<br><br><br><br><div><span class="gmail_quote">2007/2/22, 3APA3A <<a href="mailto:3APA3A@security.nnov.ru">3APA3A@security.nnov.ru
</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Title: Microsoft Windows 2000/XP/2003/Vista ReadDirectoryChangesW
<br> informaton leak<br>Author: 3APA3A, <a href="http://securityvulns.com">http://securityvulns.com</a><br>Affected: Microsoft Windows 2000,XP,2003,Vista<br>Exploitable: Yes<br>Type: Remote (from local network), authentication required
<br> (NULL session was not tested).<br>Class: Information leak, insecure design<br>CVE: CVE-2007-0843<br>Original<br>Advisory: <a href="http://securityvulns.com/advisories/readdirectorychanges.asp">
http://securityvulns.com/advisories/readdirectorychanges.asp</a><br>SecurityVulns<br>news: <a href="http://securityvulns.com/news/Microsoft/Windows/ReadDirector.html">http://securityvulns.com/news/Microsoft/Windows/ReadDirector.html
</a><br><br><br>Intro:<br><br>It's very simple yet interesting vulnerability. ReadDirectoryChangesW()<br>API allows application to monitor directory changes in real time.<br>bWatchSubtree parameter of this functions allows to monitor changes
<br>within whole directory tree with of monitored directory. To monitor<br>changes directory must be open with LIST (READ) access. Function returns<br>the list of modified files with a type of modification. File
<br>modification refers to any modification of file record in directory.<br><br>Vulnerability:<br><br>ReadDirectoryChangesW() doesn't check user's permissions for child<br>child objects, making it's possible to retrieve information about
<br>objects user has no "LIST" permissions.<br><br>Impact:<br><br>Any unprivileged user with LIST access to parent directory can monitor<br>any files in child directories regardless of subdirectories and files
<br>permissions. Because by default Windows updates access time of any<br>accessed files on NTFS volumes, it makes it possible for user to gather<br>information about NTFS-protected files, their names and time of access
<br>to the files (reading, writing, creation, deletion, renaming, etc).<br>Filenames may contain sensitive information or leak information about<br>user's behavior (e.g. cookies files).<br><br>In addition to it's own impact, this vulnerability elevates impact of
<br>few different vulnerabilities and common practices, to be reported<br>later.<br><br>Exploit:<br><br><a href="http://securityvulns.com/files/spydir.c">http://securityvulns.com/files/spydir.c</a><br><br> compiled version of Spydir is available from
<br><br><a href="http://securityvulns.com/soft/">http://securityvulns.com/soft/</a><br><br> Usage example:<br><br>spydir \\corpsrv\corpdata<br><br>I believe you find this utility useful regardless of this security<br>
issue. It shows names of accessed/modified files for given directory in<br>real time (it seems there are non-security bugs in ReadDirectoryChangesW<br>implementations, e.g. you can not see non-ASCII names and some changes
<br>are missing).<br><br>Workaround:<br><br>Avoid creation of more secure folder in less secure ones. Avoid using<br>sensitive data in documents naming.<br><br>Vendor (Microsoft):<br><br>January, 17 2006 Initial vendor notification
<br>January, 18 2006 Vendor reply (assigned)<br>January, 26 2006 2nd vendor notification<br>February, 7 2006 3rd vendor notification<br>February, 9 2006 Vendor accepted vulnerability as "service pack
<br> class" for Windows XP and Windows 2003.<br>February, 9 2006 Accepted to wait until SP<br>February, 22 2006 Vendor gives SP timelines (late 2006 for W2K3<br> SP2 and 2007 for XP SP3)
<br>February, 22 2007 Public release, because Windows Vista is<br> released with same vulnerability.<br><br><br>_______________________________________________<br>Full-Disclosure - We believe in it.
<br>Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html">http://lists.grok.org.uk/full-disclosure-charter.html</a><br>Hosted and sponsored by Secunia - <a href="http://secunia.com/">http://secunia.com/
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Andres Tarasco