What's this bulletin about?
Microsoft Security Bulletin MS00-059 announces the availability of a patch that eliminates a vulnerability in the Microsoft® virtual machine (Microsoft VM). The vulnerability could allow a malicious user operating a web site to visit other web sites in the guise of a user who visited his site.
What's the scope of the vulnerability?
This vulnerability would allow a malicious web site operator to browse other web sites posing as another user -- one who he had enticed into visiting his site.
The vulnerability would enable the malicious user to use the identity of the other user, but it would not allow him to compromise passwords or other information. The malicious user would need to know or guess the exact name of each web site he wished to visit; this could be difficult for sites on the user's intranet.
I heard about something called "Brown Orifice". Is this vulnerability related to it?
No. "Brown Orifice" is a program that exploits multiple vulnerabilities in several vendors' Java implementations. The vulnerability at issue here is different from those exploited by "Brown Orifice", although it is similar in scope and effect to one of them.
Are all Java programs affected by this vulnerability?
No. There are two general classes of Java programs: Java applications, which are hosted on the same machine they run on, and Java applets, which are hosted on web sites and run on user's computers when they visit the site. Only Java applets are affected by this vulnerability.
Because Java applets are untrusted code, they are treated differently than Java applications. They are run within a virtual machine that uses a "sandbox" to restrict what they can do. In general, the sandbox is designed to prevent a Java applet from taking any inappropriate actions on the user's computer. The vulnerability at issue here involves a flaw in the sandbox.
What is the cause of this vulnerability?
By design, an unsigned Java applet should only be able to communicate with the web site that hosted it. However, a flaw in the Microsoft VM could allow an applet to bypass this restriction and communicate with another web site.
What's the significance of the applet being signed or not?
Applets that are signed by someone the user trusts are allowed to communicate with other web sites, because they're trusted code. However, unsigned applets are not trusted, and as a result should not be able take such action. The overall issue here is that the vulnerability allows an untrusted - that is, an unsigned - applet to take actions that only a truste applet should be able to take.
What's the problem with allowing an unsigned applet to communicate with other web sites?
If a malicious web site operator could persuade a user to visit his web site, he could create an applet on the visiting user's computer that exploited the vulnerability. This would allow the malicious user to visit web sites posing as the visiting user.
So what? Couldn't the malicious user just visit the web sites himself?
In some cases, the vulnerability wouldn't confer any benefit on the malicious user. For instance, if his applet visited www.microsoft.com, it wouldn't be of any value to him, because the Microsoft web site is already open to anyone who wants to visit.
However, suppose the visiting user were on a corporate intranet. The applet could visit sites on the intranet that are normally beyond the reach of the malicious user, set up a web session, and forward the content to the malicious user's site.
Why would the applet be able to surf the web sites as the user? How would it learn his password?
The applet would not be able to learn the user's password, but in many cases - especially intranet cases - it wouldn't need to. Many intranets are configured to allow the user's logon credentials to be securely and automatically passed by the operating system when needed by a web site or other service. In such a case, the applet wouldn't need to be able to actually access the credentials in order to use them. It would simply establish a connection with an intranet site, and everything else would happen automatically.
It's important to note that, although the vulnerability does allow an applet to use the user's credentials, it does not allow it to compromise them. That is, the applet could neither read nor change the user's password. It's also important to note that if an intranet site ever displayed a dialogue asking for a password, the applet would be unable to answer it - it could only make use of automatic authentication.
What about Internet sites? Is there any risk here?
Yes. If the user had an account at, say, a banking web site and had cached the userid and password, the applet could visit that site and access personal information.
My corporate intranet is protected by a firewall. Would this prevent the applet from forwarding the information to the malicious user's web site?
No. Keep in mind that, in order to be affected by the vulnerability, a user would need to first visit a malicious user's web site. In such a case, the web session would have originated from inside the firewall, and all of the subsequently-relayed data would piggyback on that session. This would enable the applet to pass data through the firewall.
How would the malicious user know which web sites to visit?
He wouldn't. He would need to know or guess the name of each intranet or Internet web site he wanted his applet to visit.
Could the applet do anything other than visit web sites?
Yes. In addition to being able to establish web sessions (HTTP or HTTPS), the applet also could establish Telnet or FTP sessions. The risk from these protocols, though, is far less than from web sessions.
It's noteworthy that the applet could not establish sessions using the file: protocol. That is, there is no capability through this vulnerability to view, add, change or delete files, either on the local machine or on remote ones.
Could this vulnerability be exploited accidentally?
No. The set of steps needed to bypass the sandbox restrictions in this case are extremely unlikely to happen accidentally.
How do I know if I have a version of the Microsoft VM that has the vulnerability?
The easiest way to tell is by checking the software you have installed on your machine:
- If you're using IE 4.x or IE 5.x, you definitely have a version of the VM that's affected by the vulnerability. It doesn't matter what other software you have installed; if IE 4.x or 5.x are installed, you have an affected version of the VM.
- Even if you're not using a version of the IE that is affected by the vulnerability, you could still have an affected version of the Microsoft VM, as it ships as part of other products like Visual Studio. In this case, the best course is to determine the build number for the version of the Microsoft VM you are using and see if you have an affected version.
How do I determine the build number for my version of the Microsoft VM?
Open a command window:
- On Windows NT or Windows 2000, choose "Start", then "Run", then type "CMD" and hit the enter key.
- On Windows 95 or 98, choose "Start", then "Run" then type "COMMAND" and hit the enter key.
- At the command prompt, type "JVIEW" and hit the enter key.
The version information will be at the right of the topmost line. It will have a format like "5.00.xxxx", where the "xxxx" is the build number. For example, if the version number is 5.00.1234, you have build number 1234.
I've determined the build number. How do I tell if I'm affected?
Use this table to determine whether you have an affected version:
| Build Number | Status |
|---|
| 3315 or earlier | Affected by the vulnerability |
| All other versions | Not affected by the vulnerability or not a supported VM version |
Note: All users who have an affected version of the Microsoft VM should install the new VM build.
What does the fix do?
The fix to the various VM builds restores the sandbox restrictions in order to prevent this vulnerability.
Where can I get the patch?
The download location for new versions of the VM and patches is provided in the "Patch Availability" section of the security bulletin .
How do I use the patch?
Knowledge Base article Q271752 contains detailed instructions for applying the patch and updated VM builds.
How can I tell if I installed the patch correctly?
The Knowledge Base article Q271752 provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.
Note: Regardless of the version number viewed from Jview, the registry key described in the above article should be the determining factor for proper installation of this patch.
What is Microsoft doing about this issue?
- Microsoft has delivered a patch that eliminates the vulnerability.
- Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
- Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
- Microsoft has issued a Knowledge Base article Q271752 explaining the vulnerability and procedure in more detail.
Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.
