COMMAND

SYSTEMS AFFECTED

IE and Windows Scripting Host

PROBLEM

Following is based on a Microsoft Security Bulletin MS01-015.
The IE security architecture provides a caching mechanism that is
used to store content that needs to be downloaded and processed
on the user's local machine. The purpose of the cache is to
obfuscate the physical location of the cached content, in order
to ensure that the web page or HTML e-mail will work through the
IE security architecture to access the information. This ensures
that the uses of the information can be properly restricted.

A vulnerability exists because it is possible for a web page or
HTML e-mail to learn the physical location of cached content.
Armed with this information, an attacker could cause the cached
content to be opened in the Local Computer Zone. This would
enable him to launch compiled HTML help (.CHM) files that contain
shortcuts to executables, thereby enabling him to run the
executables.

In addition to eliminating this vulnerability, the patches
provided below eliminate three other vulnerabilities that either
pose significantly less risk or could only be exploited in very
restricted situations:
- A variant of the "Frame Domain Verification" vulnerability
discussed in Microsoft Security Bulletins MS00-033, MS00-055,
and MS00-093. The vulnerability could enable a malicious web
site operator to open two browser windows, one in the web site's
domain and the other on the user's local file system, and to
pass information from the latter to the former. This could
enable the web site operator to read, but not change, any file
on the user's local computer that could be opened in a browser
window.
- A vulnerability that is identical in effect to the "Frame Domain
Verification" vulnerability, but which actually results from a
flaw in Windows Scripting Host rather than IE. Because it could
only be exploited via IE, we have provided the patch here.
- A vulnerability that affects how Telnet sessions are invoked via
IE. By design, telnet sessions can be launched via IE.
However, a vulnerability exists because when doing so, IE will
start Telnet using any command-line options the web site
specifies. This only becomes a concern when using the version
of the Telnet client that installs as part of Services for Unix
(SFU) 2.0 on Windows NT(r) 4.0 or Windows(r) 2000 machines. The
version of the Telnet client in SFU 2.0 provides an option for
creating a verbatim transcript of a Telnet session. An attacker
could start a session using the logging option, then stream an
executable file onto the user's system in a location that would
cause it to be executed automatically the next time the user
booted the machine. The flaw does not lie in the Telnet client,
but in IE, which should not allow Telnet to be started remotely
with command-line arguments.

None of the vulnerabilities could be exploited without some user
action - either browsing to the attacker's site or opening a mail
from him. Customers who exercise safe browsing habits would be
less likely visit untrustworthy sites, and customers who have used
the Security Zones feature to restrict what HTML mail can do would
be less likely to be affected by this vulnerability.

The variants of the "frame domain verification" vulnerability
discussed above could only be used to view files, and only file
types that can be opened in a browser window.

The vulnerability affecting Telnet invocation is only a concern
for customers who are using the Telnet client that ships as
part of Services for Unix 2.0. Other versions of Telnet do not
include the command-line feature to create log files.

This vulnerability occurs as a result of Internet Explorer
executing the "telnet" command and passing command line
parameters, specified in the URL, to the telnet program. The
Windows 2000 Telnet client contains a client side logging option,
which is used to log all telnet session data to a file specified
by this option. By specifying the "-f" flag to the telnet
command, accompanied by a filename, all session text is logged to
this file.

This vulnerability was discovered by Oliver Friedrichs.

This vulnerability can be reproduced by giving Internet Explorer a
URL such as the following:

telnet:-f%20\file.txt%20host

The above example will cause Internet Explorer to invoke the
telnet client and cause it to connect to the host "host", logging
all output to the file "\file.txt". An attacker can cause
arbitrary data to be written to this file by setting up a rogue
server, such as netcat, which is listening on the telnet port,
sending their desired data to the client. Arbitrary port numbers
can also be specified on the telnet command line, so the server
need not listen on port 23.

Furthermore, the invocation of the telnet client can be hidden
within existing HTML, automating it's execution. This
vulnerability can also be exploited via Outlook, which by default
will automatically process HTML messages.

The above example will cause data that is received from port 8000
on the host "host" to be written to the file "boom.bat" in the
startup directory for all users. Assuming the logged in user has
the appropriate permissions, this will create a batch file that is
executed upon any future user logon. Note that if the username is
known to the attacker, this can also be directed towards the
logged in user, who will have permission to create this file.

SOLUTION

A patch is available to fix this vulnerability. Please read the
Security Bulletin

http://www.microsoft.com/technet/security/bulletin/ms01-015.asp

for information on obtaining this patch.

The patches for Windows Scripting Host referenced in Microsoft
Security Bulletin MS01-015 are not clearly identified on the
pages referenced in the bulletin

http://www.microsoft.com/msdownload/vbscript/scripting51.asp
http://www.microsoft.com/msdownload/vbscript/scripting.asp

These pages contain only downloads for the complete WSH 5.1 and
5.5, respectively, with no mention of updates for the problem
described in the security bulletin. The pages says that they were
last updated 12/15/2000 (months before the security bulletin was
issued). Microsoft Security Response Center verified that the WSH
pages referenced in the security bulletin and above do contain the
update for the problem described in the security bulletin even
though the pages have no reference to this update. Tests of
installing the WSH 5.5 Win9xNT version shows that the downloaded
version is indeed 5.5.0.5824.