RE: [Full-Disclosure] Proof of concept for Windows Workstation Se rvice overflow
Looking at his little bit of information in the advisory
(http://www.eeye.com/html/Research/Advisories/AD20031111.html)
"...a buffer overflow happens on the specified host if the debug file is
writeable.
Generally, the "debug" subdirectory in the Windows directory is not
writeable by everyone if the drive is formatted as NTFS, which means that we
cannot append to the log using a null session. The WsImpersonateClient() API
is called before opening the log file, and if the connected client does not
have the privilege to write to the log file, then CreateFile() will fail,
and the vulnerable call to vsprintf() is not performed. So, in this case, we
can exploit FAT32 systems (which do not support ACLs on directories), or
systems where the "%SYSTEMROOT%\debug" directory is writeable by everyone.
However, there are some extended RPC functions implemented in Windows XP
which open the logfile before calling WsImpersonateClient()... "
So my guess is that if this gets to be a worm, it probably will affect
mostly XP systems and not Windows 2000 systems (given that NTFS is a default
file type for W2k and that by default this is not writeable by a NULL
session). So that reduces the number of potential worm candidates and along
with this needs to use the same ports as Blaster the list of targets grows
smaller (because of the XP firewall), in itself it does not look to have the
same level of potential impact as Blaster.
What are your thoughts?
aromogcraigjngigi