Microsoft Security Bulletin MS02-013 - Critical

Technical description:

On March 4, 2002, Microsoft released the first version of this bulletin. On March 18, 2002, Microsoft re-released this bulletin to make customers aware of an additional vulnerability that is eliminated by the updated VM (Microsoft VM build 3805). Customers who have previously installed the new build do not need to take any additional action.

The Microsoft VM is a virtual machine for the Win32® operating environment. The Microsoft VM is available for Windows 95, Windows 98, ME, Windows NT® 4.0, Windows 2000, and Windows XP. It is also available as part of Internet Explorer 6 and earlier.

A new build of the VM (build 3805) is available, which eliminates two security vulnerabilities. The first vulnerability is the result of a flaw affecting how Java requests for proxy resources are handled. A malicious Java applet could exploit this flaw to re-direct web traffic once it has left the proxy server to a destination of the attacker's choice.

An attacker could use this flaw to send a user's Internet session to a system of his own control, without the user being aware of this. The attacker could then forward the information on to the intended destination, giving the appearance that the session was behaving normally. The attacker could then send his own malicious response, making it seem to come from the intended destination, or could discard the session information, creating the impression of a denial of service. Additionally, the attacker could capture and save the user's session information. This could enable him to execute a replay attack or to search for sensitive information such as user names or passwords.

A system is only vulnerable if IE is used in conjunction with a proxy server. Users whose browsers are not behind a proxy server are not vulnerable to this vulnerability. However, those users would be vulnerable if they changed their browser to use a proxy server at a later date.

The second vulnerability is a new discovered variant of the "Virtual Machine Verifier" issue first discussed in MS99-045. Like most programming languages, the Java language provides the means to convert types by means of casting operations. Most commonly, these are used to convert data types, although other more complex type conversion is possible. A flaw exists in the security checks on casting operations within the Microsoft VM. A vulnerability results because it is possible for an attacker to exploit this flaw and use it to execute code outside of the sandbox. This code would execute as in the context of the user, and would only be limited by those constraints which govern the user herself.

The flaw only affects Java applets, it does not affect Java applications. To mount a successful attack, the malicious user would have to specially craft a Java applet at the binary level, post it on his site, and entice the intended target to visit his site.

Mitigating factors:

HTTP Proxy Redirection Vulnerability:

• The vulnerability only affects configurations that utilize a proxy server. Customers who are not using a proxy server are not at risk from this vulnerability.
• Best practices strongly recommend using SSL to encrypt sensitive information such as user names, passwords and credit card numbers. If this has been done, sensitive information will be protected from examination and disclosure by an attacker exploiting this vulnerability.

Virtual Machine Verifier Variant:

• The vulnerability only affects Java applets, not Java applications.
• Exploiting the vulnerability requires detailed specific knowledge and skills.
• An attacker must lure an intended target to a site under his control where he has posted the malicious applet.
• Java applets and other mobile code can be blocked at the firewall perimeter through the use of application filtering software.

Severity Rating:

HTTP Proxy Redirection Vulnerability:

Virtual Machine Verifier Variant:

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. This vulnerability affects the disclosure of personal information, and is most likely to have an impact on client systems.

Vulnerability identifier:

• HTTP Proxy Redirection Vulnerability: CAN-2002-0058
• Virtual Machine Verifier Variant: CAN-2002-0076

Tested Versions:

Microsoft tested Microsoft VM builds 3167 and later, which ship with IE 5.0 and later to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Why was this bulletin re-released?
This bulletin was re-released to make customers aware of an additional vulnerability that is eliminated by the updated VM (Microsoft VM build 3805 or later).

Why have you chosen to announce this additional vulnerability at this time? 
On March 4, 2002, we released an updated VM which eliminates all previously known vulnerabilities, in addition to two new vulnerabilities. The additional vulnerability is now being announced publicly as part of a co-ordinated joint announcement by all vendors on a specified date.

Why didn't you announce this vulnerability before? 
We have deferred making this issue public until the joint announcement date to ensure that all vendors' customers are able to protect them selves fully. .

Have you re-released the patch? 
No. The new VM build we released in the original version of this bulletin (build 3805) eliminates all known vulnerabilities. If you installed the new build when it was originally released, you do not need to take any additional action.

What new vulnerabilities are eliminated by this patch? 
There are two vulnerabilities addressed by this patch:

• A vulnerability related to HTTP Proxy Redirection.
• A variant of MS99-045

What's the scope of the first vulnerability? 
This is session hijacking vulnerability. This vulnerability could allow a maliciously crafted Java applet to silently re-route all browser traffic to the applet's host without the user's knowledge. Once an attacker was in possession of the re-routed browser traffic, he could take any action or combination of actions of his choosing. This includes handling the browser request, recording the session information, or forwarding the request on to the intended destination. It's important to note that this capability could allow a malicious party to record a user's session information and possibly search for usernames, passwords, or credit card numbers sent in clear text.
This vulnerability could only be exploited if Internet Explorer was configured to access Internet resources via a proxy server. Users whose browsers are not configured to use a proxy server are not at risk from this vulnerability. Additionally, because secure HTTP (HTTPS) is encrypted using SSL, any HTTPS traffic that was captured by an attack that exploited this vulnerability would not readable in plain text. This means that usernames and passwords sent using HTTPS are much less at risk than information sent in plain text using HTTP. A malicious applet attempting to exploit this vulnerability would be active until the browser's process exited by exiting all open IE sessions.

What causes the vulnerability?
This vulnerability results from the way that certain requests for proxy service in Java are handled. In configurations where IE is configured to use proxy services, a particularly crafted Java program, sometimes called an applet could exploit this vulnerability to forward browser traffic.

What is a Proxy Server?
A proxy server is a server that executes web requests on behalf of clients, rather than having the client execute the request on its own. For example, when a user requests a page from a site and the user's browser is configured to use a proxy server, the browser contacts the proxy server instead of contacting the site. The proxy server then passes the request on to the site and receives the response. The proxy server then passes the response back to the user's browser. Usually, a proxy is used as a gateway between a private network, such as a corporate intranet and the public Internet.

What's wrong with how IE handles Java requests through a proxy server?
There is a specific isolated issue with the way that Java requests are handled when IE is configured to use a proxy server. A specially crafted applet could cause the proxy server to send packets to a destination of the attacker's choice rather than to the intended destination.

Is this a problem with Microsoft Proxy Server or Internet Security and Acceleration Server 2000?
The vulnerability does not result from a problem with any proxy server. The particular proxy server in use does not affect the scope of the vulnerability. The issue relates to the way IE handles requests from Java applets to use any proxy server.

How would someone exploit this vulnerability?
To successfully exploit this vulnerability, a malicious user would have to develop a specially crafted Java applet and host it on their web site. To exploit this vulnerability effectively, the user would have to maintain an accessible site where he could re-direct the hijacked traffic.

What is Secure HTTP (HTTPS) and how does it protect me from this vulnerability?
First, it's important to remember that HyperText Transfer Protocol (HTTP) by design sends information in human-readable clear-text. This means that if an attacker were able to examine the information sent back and forth during your web session, he could read that information. If you included usernames or passwords, he would be able to read that information.
Secure HTTP (HTTPS) addresses this issue by using Secure Sockets Layer (SSL) encryption to obscure sensitive information. Information that is sent using HTTPS is NOT in human readable form because it is encrypted.
Because this vulnerability can allow a malicious individual to redirect web traffic to a site of his choosing, any sensitive information that is in human-readable form would potentially be at risk. It's recommended as a best practice that any sensitive information, such as user names, passwords, and credit card numbers, be sent using HTTPS.

How can I know if I'm sending information using HTTP or HTTPS?
There are two ways to know for sure when you're using HTTPS rather than HTTP. First, a small gold lock will appear in the lower right corner of the IE window when your information is being sent using HTTPS. You can also check to see that the URL shows HTTPS rather than HTTP.

What could someone do with this vulnerability?
This vulnerability could allow someone to redirect web traffic to a site of his choosing. Because of this, there are several options available for malicious use.

• Potentially the most serious attack would be to forward traffic as normal, giving the user no clue that his traffic was being redirected. The malicious user could then capture the traffic and examine it for sensitive information, such as passwords.
• A malicious attacker could also choose to handle the redirected traffic himself. Because the user would have no indication that their session had been redirected, this would allow the malicious user to "spoof" the user's intended session.
• Finally, a malicious user could simply discard the redirected traffic, creating a denial of service.

How long would the effect of exploiting the vulnerability last?
An attacker who exploited this vulnerability would be able to use this vulnerability throughout a user's browsing session until the user closed the browser. The user's full session after visiting the attacker's site could potentially be "sniffed" by the attacker.

Could someone use this vulnerability to "sniff" other users' sessions?
No. The vulnerability only affects a user's own session. It cannot be used to affect the session of any other user.

Could this vulnerability be exploited by accident?
No. The information required to exploit this vulnerability is very specific and very unlikely to be used accidentally.

What's the scope of the second vulnerability? 
This is a new variant of vulnerability originally discussed in Microsoft Security Bulletin MS99-045. It is a privilege elevation vulnerability. An attacker who was able to successfully exploit this vulnerability would be able to run code that could take actions on the user's system that the user herself was capable of. This could potentially include adding, changing or deleting data or configuration information.
The attacker's actions would be limited by any restrictions which govern the user's actions. Thus, in an environment where accounts adhere to the rule of least privilege, the attacker may be severely limited in the actions his program could take. In addition, this vulnerability only affects Java applets; Java programs are not able to exploit this vulnerability.

What causes the vulnerability? 
The vulnerability results because it is possible for a specially malformed Java applet to escape the sandbox by performing an illegal cast operation. If an attacker were to construct an applet that bypasses the sandbox security mechanism in this way, he could cause code of his choice to run outside of the sandbox and take action as if it were the user.

Are there any differences between this vulnerability and the one discussed in Security Bulletin MS99-045? 
No. This new variant is identical in scope, and exploitability. The only difference is a slight variation in the cause.

What does the updated Microsoft VM do?
The updated Microsoft VM eliminates the vulnerability by changing how proxy requests from Java applets are handled. Once the updated VM is installed and applied, malicious Java applets cannot redirect traffic.

How do I determine the build number for my version of the Microsoft VM?

• Open a command window:
• On Windows NT, Windows 2000, or Windows XP choose "Start", then "Run", then type "CMD" and hit the enter key. On Windows 95,98, or ME , 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.

Microsoft Java Virtual Machine is no longer in support. For more information, please refer to Microsoft Java Virtual Machine and Microsoft Java Virtual Machine Support.