Possible problems with patch for MS00-086

A recent report <http://www.securityfocus.com/archive/1/147109&gt; suggests
that;

http://IISServer/scripts/somefile.bat/..&#37;C1&#37;9C..&#37;C1&#37;9C..&#37;C1&#37;9Cwinnt/system32
/cmd.exe?/c%20dir%20C:\
(wrapped)

might yield a directory listing on IIS 5.0 boxes that have applied the fix
listed in Microsoft Security Bulletin MS00-086
(http://www.microsoft.com/technet/security/bulletin/MS00-086.asp&#41;

Assuming that one has a scripts directory (i.e. you haven't already
removed
it), or some other directory with execute permissions…and assuming that
directory is on the same partition as your %systemroot% directory…and
assuming you have left "cmd.exe" , "command.com", or some other
hacker-useful executable lying around some known or obvious
location…then
it seems that the fix has re-introduced the …\ problem.

The perils of what might happen should someone be able to do a …\
execution
on your IIS box, assuming the assumptions above are also true, have been
discussed at length in recent weeks on NTBugtraq (and virtually every
other
Security forum in the world).

Ergo, if you haven't already done something to make most of the above
assumptions untrue for your IIS box you somehow missed the point of all of
those previous discussions…namely, until Microsoft completely uncouples
the "DOS" intrinsic environment (the ability to do …\, and other
intrinsic
DOS commands) from any and all URL processing, you must do it for
yourself.

1. Remove, or at least rename, CMD.EXE and COMMAND.COM. Might as well do
   FTP, Telnet, etc… (and btw, don't alter your COMSPEC variable to reflect
   the changed name…;-])

2. Point your "scripts" virtual site to a directory that's not on your
   %systemroot% partition, and unless you're using CGI's, set the "Execute
   Permissions" to "Scripts Only" (that's assuming you're doing scripting in
   the first place, otherwise disable it by setting "Execute Permissions" to
   "None").

3. Check your MDAC directory and any other virtual directories present on
   your site (particularly those that are part of your Default Web). Look for
   unnecessary/unused directories, kill them, delete them, permission them
   such
   that nobody can access them.

4. If you can't do any of the above, hire someone who can (or can tell you
   what your site needs to do)…;-]

Cheers,
Russ - Surgeon General of TruSecure Corporation