Re[2]: [Full-disclosure] Microsoft Windows 2000/XP/2003/Vista Re
Dear Andres Tarasco,
Agree, but actually, I mean to store sensitive data in different
location (different network share).
There will be one more advisory, it will demonstrate symlink-like
attacks on Windows. In the same advisory I plan to discuss problem of
secure data in insecure folder mode deeply.
E.g. it's quite impossible for administrator to _create_ secure folder
in insecure one without not-quite-race conditions this folder will be
available for different bad things (without deleting network share, of
cause). Under POSIX system this problem is solvable with umask, for
Windows it seems it was never discussed.
--Thursday, February 22, 2007, 2:29:49 PM, you wrote to 3APA3A@security.n=
nov.ru:
AT> Hi,
AT> You told that as a workaround that we should never allow "creation o=
f more
AT> secure folder in less secure ones."
AT> I agree but, as i see.., that means that also allowing the "Bypass t=
raverse
AT> checking" policy is also a bad idea.
AT> Anyway, there are several scenarios where we could not protect us aga=
inst
AT> that threat easily, like for example a shared environment with termin=
al
AT> server/citrix where all our stored documents can be stolen.
AT> In that case, only a software restriction policy will protect us.
AT> regards,
AT> Andres Tarasco
AT> 2007/2/22, 3APA3A <3APA3A@security.nnov.ru>:
>>
>>
>>
>> Title: Microsoft Windows 2000/XP/2003/Vista ReadDirectoryChan=
gesW
>> informaton leak
>> Author: 3APA3A, http://securityvulns.com
>> Affected: Microsoft Windows 2000,XP,2003,Vista
>> Exploitable: Yes
>> Type: Remote (from local network), authentication require=
d
>> (NULL session was not tested).
>> Class: Information leak, insecure design
>> CVE: CVE-2007-0843
>> Original
>> Advisory:
>> http://securityvulns.com/advisories/readdirectorychanges.asp
>> SecurityVulns
>> news:
>> http://securityvulns.com/news/Microsoft/Windows/ReadDirector.html
>>
>>
>> Intro:
>>
>> It's very simple yet interesting vulnerability. ReadDirectoryChangesW=
()
>> API allows application to monitor directory changes in real tim=
e.
>> bWatchSubtree parameter of this functions allows to monitor chang=
es
>> within whole directory tree with of monitored directory. To monit=
or
>> changes directory must be open with LIST (READ) access. Function retur=
ns
>> the list of modified files with a type of modification. Fi=
le
>> modification refers to any modification of file record in directory.
>>
>> Vulnerability:
>>
>> ReadDirectoryChangesW() doesn't check user's permissions for chil=
d
>> child objects, making it's possible to retrieve information abo=
ut
>> objects user has no "LIST" permissions.
>>
>> Impact:
>>
>> Any unprivileged user with LIST access to parent directory can monit=
or
>> any files in child directories regardless of subdirectories and fil=
es
>> permissions. Because by default Windows updates access time of a=
ny
>> accessed files on NTFS volumes, it makes it possible for user to gath=
er
>> information about NTFS-protected files, their names and time of acce=
ss
>> to the files (reading, writing, creation, deletion, renaming, etc=
).
>> Filenames may contain sensitive information or leak information abo=
ut
>> user's behavior (e.g. cookies files).
>>
>> In addition to it's own impact, this vulnerability elevates impact =
of
>> few different vulnerabilities and common practices, to be report=
ed
>> later.
>>
>> Exploit:
>>
>> http://securityvulns.com/files/spydir.c
>>
>> compiled version of Spydir is available from
>>
>> http://securityvulns.com/soft/
>>
>> Usage example:
>>
>> spydir \\corpsrv\corpdata
>>
>> I believe you find this utility useful regardless of this securi=
ty
>> issue. It shows names of accessed/modified files for given directory =
in
>> real time (it seems there are non-security bugs in ReadDirectoryChange=
sW
>> implementations, e.g. you can not see non-ASCII names and some chang=
es
>> are missing).
>>
>> Workaround:
>>
>> Avoid creation of more secure folder in less secure ones. Avoid usi=
ng
>> sensitive data in documents naming.
>>
>> Vendor (Microsoft):
>>
>> January, 17 2006 Initial vendor notification
>> January, 18 2006 Vendor reply (assigned)
>> January, 26 2006 2nd vendor notification
>> February, 7 2006 3rd vendor notification
>> February, 9 2006 Vendor accepted vulnerability as "service pa=
ck
>> class" for Windows XP and Windows 2003.
>> February, 9 2006 Accepted to wait until SP
>> February, 22 2006 Vendor gives SP timelines (late 2006 for W2K=
3
>> SP2 and 2007 for XP SP3)
>> February, 22 2007 Public release, because Windows Vista is
>> released with same vulnerability.
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
--=20
~/ZARAZA http://securityvulns.com/
=C6=E0=EB=EE =EC=ED=E5 =ED=E5 =EF=EE=ED=E0=E4=EE=E1=E8=F2=F1=FF (=D1. =CB=
=E5=EC)