Microsoft Security Bulletin MS02-069 - Critical

Technical description:

The Microsoft VM is a virtual machine for the Win32® operating environment. The Microsoft VM shipped in most versions of Windows (a complete list is available in the FAQ), as well as in most versions of Internet Explorer.

A new version of the Microsoft VM is available, which includes all previously released fixes for the VM, as well as fixes for eight newly reported security issues. The attack vectors for all of the new issues would likely be the same. An attacker would create a web page that, when opened, exploits the desired vulnerability, and either host it on a web page or send it to a user as an HTML mail.

The newly reported security issues are as follows:

• A security vulnerability through which an untrusted Java applet could access COM objects. By design, COM objects should only be available to trusted Java programs because of the functionality they expose. COM objects are available that provide functionality through which an attacker could take control of the system.
• A pair of vulnerabilities that, although having different underlying causes, would have the same effect, namely, disguising the actual location of the applet's codebase. By design, a Java applet that resides on user storage or a network share has read access to the folder it resides in and all folders below it. The vulnerabilities provide methods by which an applet located on a web site could misrepresent the location of its codebase, to indicate that it resided instead on the user's local system or a network share.
• A vulnerability that could enable an attacker to construct an URL that, when parsed, would load a Java applet from one web site but misrepresent it as belonging to another web site. The result would be that the attacker's applet would run in the other site's domain. Any information the user provided to it could be relayed back to the attacker.
• A vulnerability that results because the Microsoft VM doesn't prevent applets from calling the JDBC APIs - a set of APIs that provide database access methods. By design, these APIs provide functionality to add, change, delete or modify database contents, subject only to the user's permissions.
• A vulnerability through which an attacker could temporarily prevent specified Java objects from being loaded and run. A legacy security mechanism known as the Standard Security Manager provides the ability to impose restrictions on Java applets, up to and including preventing them from running altogether. However, the VM does not adequately regulate access to the SSM, with the result that an attacker's applet could add other Java objects to the "banned" list.
• A vulnerability through which an attacker could learn a user's username on their local system. The vulnerability results because one particular system property, user.dir, should not be available to untrusted applets but, through a flaw, is. While knowing a username would not in itself pose a security risk, it could be useful for reconnaissance purposes.
• A vulnerability that results because it's possible for a Java applet to perform an incomplete instantiation of another Java object. The effect of doing so would be to cause the containing application - Internet Explorer - to fail.

Mitigating factors:

All of the vulnerabilities share a pair of common mitigating factors:

• The web-based attack vector would be blocked if the user had disabled Java applets in the Internet Explorer security zone in which the attacker's web site rendered.
• The email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

COM Object Access Vulnerability:

• The vulnerability represents a target of opportunity only. The attacker would have no means of ensuring that sensitive data would be located in system memory, cookies, the clipboard, or other locations.

CODEBASE Spoofing Vulnerabilities:

• The attacker's access to files, including those on remote shares, would be limited to those of the user. If the user had only limited permissions, so would the attacker.

Domain Spoofing Vulnerability:

• The vulnerability could only be exploited if the user visited the attacker's site en route to visiting a third-party site.
• The effect of exploiting the vulnerability would apply only to the current web session.

JDBC API Vulnerability:

• To exploit this vulnerability, the attacker would need to know the names of each data source he or she wanted to access. In most cases, this would require the attacker to have insider knowledge of the user's network.
• The attacker would gain only the user's own permissions to the data sources. For instance, if the user had only read access to a particular database, so would the attacker.

Standard Security Manager Access Vulnerability:

• The effect of exploiting this vulnerability would only persist during the current browser session.
• The vulnerability provides no means of modifying an applet's functioning - only preventing it from running.

User.dir Exposure Vulnerability:

• Knowing a user's username would not, by itself, enable an attacker to take any action against the user. The sole value in learning this information would be for reconnaissance purposes, in the hope of using it in some future, unspecified attack.

Incomplete Java object Instantiation Vulnerability:

• This vulnerability would only enable the attacker to cause Internet Explorer to fail - it would not enable the attacker to cause Windows itself, or any other applications, to fail.
• The user could restore normal operation by restarting the browser.

Severity Rating:

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.

Vulnerability identifiers:

• COM Object Access Vulnerability: CAN-2002-1257
• CODEBASE Spoofing Vulnerabilities: CAN-2002-1258
• Domain Spoofing Vulnerability: CAN-2002-1259
• JDBC API Vulnerability: CAN-2002-1260
• Standard Security Manager Access Vulnerability: CAN-2002-1261
• User.dir Exposure Vulnerability: CAN-2002-1325
• Incomplete Java object Instantiation Vulnerability: CAN-2002-1263

Tested Versions:

Microsoft tested VM builds 5.0.3167 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What security vulnerabilities are eliminated by the new VM build?
This VM build includes all previously released security fixes, as well as fixing eight newly reported security vulnerabilities:

• A vulnerability that could enable an attacker to gain complete control over another user's system.
• A pair of vulnerabilities that could enable an attacker to read files on a user's system or on network shares the user had access to.
• A vulnerability that could, under unusual conditions, enable an attacker to interpose a program from his or her web site onto a third-party web site.
• A vulnerability that could, under unusual conditions, enable an attacker to access databases in the guise of a user.
• A vulnerability through which an attacker could temporarily prevent other web sites from operating correctly on a particular user's system.
• A vulnerability that could enable an attacker to conduct reconnaissance that could be useful in targeting a user for later attacks.
• A vulnerability that could enable an attacker to cause Internet Explorer to fail if a user visited the attacker's web site.

What is the Microsoft VM?
The Microsoft virtual machine (Microsoft VM) enables Java programs to run on Windows platforms. The Microsoft VM is included in most versions of Windows and Internet Explorer. The vulnerabilities here affect all customers who have the Microsoft VM.

I don't know if the Microsoft VM is installed on my system. How can I tell?
If you're using any of the following versions of Windows, you definitely have the Microsoft VM installed:

• Microsoft Windows 95
• Microsoft Windows 98 and 98SE
• Microsoft Windows Millennium
• Microsoft Windows NT 4.0, beginning with Service Pack 1
• Microsoft Windows 2000
• Microsoft Windows XP, beginning with Service Pack 1

The Microsoft VM also shipped as part of several versions of Internet Explorer and other products and was incorporated into Windows XP via install on demand. If you're in doubt about whether you have it installed, do the following:

1. Select Start, then Run.
2. Open a command box, as follows:
   • If you are running Windows 98 or Windows Millennium, type "command" (without the quotes), then hit the enter key.
   • If you are running Windows NT 4.0, Windows 2000, or Windows XP, type "cmd" (without the quotes), then hit the enter key.
3. In the resulting command box, type "Jview" (without the quotes). If a program runs, you have the Microsoft VM installed. If you receive an error saying that no program by that name exists, you don't.

Is this a new version of the Microsoft VM?
Yes, Microsoft VM build 3809 is a new release of the Microsoft VM.

How can I tell what version of the Microsoft VM I'm using?
Here's how to determine the build number you're using:

1. Select Start, then Run.
2. On Windows 95, 98, or Me, type "command" (without the quotes). On Windows NT 4.0, 2000, or XP, type "cmd" (again, without the quotes). Hit the enter key.
3. In the result command box, type "Jview" (without the quotes) and hit the enter key.
4. In the topmost line of the resulting listing, you should see a version number of the form x.yy.zzzz. The final four digits are the version number.

Once I know the version number, what should I do?
Use the table below to determine the right action.

COM Object Access Vulnerability (CAN-2002-1257):

What's the scope of this issue?
This vulnerability could enable an attacker's Java applet to gain control over another user's system. This would enable the attacker to take any desired action on the user's system; for instance, the attacker could add, delete or change data on the user's system; communicate with web sites; load and run programs; reformat the hard drive, and so forth.
The vulnerability could be exploited via either a web site or an HTML mail, but the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerability?
The vulnerability results because it's possible for an untrusted Java applet to access COM objects, which enable a variety of actions on the computer to be taken.

What are COM objects?
Component Object Model (COM) is a Microsoft technology that enables developers to build single-purpose software modules, called components, that can be used by other applications. For instance, a developer might build a COM object that displays a particular type of dialog box. The value of doing this is that any other applications that needed to display that type of dialog box could simply call the COM object rather than implementing the dialog box itself.

What do COM objects have to do with Java?
Java programs, like other types of applications, can use COM objects. The Microsoft VM provides a number of "COM wrappers" that make it possible for Java programs to invoke COM objects.

How did earlier versions of the Microsoft VM expose COM functionality?
By design, only trusted Java programs should be able to use COM objects - they can expose powerful functionality, and untrusted Java applets should be barred from doing so. Although the Microsoft VM has security checks to prevent Java applets from invoking COM objects, there is a method of invoking them that bypasses the checks.

What would this vulnerability enable an attacker to do?
The vulnerability could enable a Java applet to invoke COM objects. The specific effect of doing this would depend on the particular COM object that the attacker's applet used. However, COM objects are available to carry out a wide variety of actions, including ones that would pose a danger if invoked by an attacker. For instance, ActiveX controls (which are COM objects) are present by default that would enable data to be manipulated on the user's system, programs to be run, and so forth.

Who could exploit the vulnerabilities?
The vulnerabilities could be exploited by any attacker who was able to get another user to run a Java applet of the attacker's choosing. There are two methods by which the attacker might seek to do this:

• By hosting an applet that exploits the issue on a web site controlled by the attacker.
• By including an applet that exploits the issue in an HTML mail and sending it directly to selected users.

What risk would the web-based attack vector pose?
The advantage to the attacker of hosting the applet on a web site is that most users' browsers are configured to allow Java applets on web sites to run. The disadvantage to the attacker is that he would have no way to compel someone to visit the site. The user would need to either voluntarily visit the attacker's site, or click on a hyperlink (hosted on another web page, an email, etc.) that would take them there.

What risk would the mail-based attack vector pose?
The advantage to the attacker of sending the applet in an HTML mail is that he or she could target specific users - that is, the attacker wouldn't need to wait for users to visit his or her site, but instead could send the applet directly to them. The disadvantage to the attacker is that most recent Microsoft mail clients do not allow Java applets in email to run. For instance, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) prevent Java applets from running in their default configurations. Likewise, Outlook 98 and 2000 prevent Java applets from running if the Outlook Email Security Update has been installed.

How does the new VM build address the vulnerability?
The patch blocks the scenario discussed above, and ensures that all methods of invoking COM objects are subject to proper security checks.

CODEBASE Spoofing Vulnerabilities (CAN-2002-1258):

What's the scope of these vulnerabilities?
These two vulnerabilities stem from different issues, but have exactly the same effect. Either could enable an attacker to read - but not change, add or delete - files from another user's system, and potentially from other network shares that the user has read access to.
Although the vulnerabilities could be exploited via either a web site or an HTML mail, the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerabilities?
The vulnerabilities stem from two issues, both of which make it possible to spoof the location specified in CODEBASE parameter in the APPLET tag.

What's an APPLET tag?
APPLET is a command (or, in HTML parlance, a tag) that, when included in a web page, causes the browser to load and run a particular Java applet.

What's the CODEBASE parameter, and what does it do?
CODEBASE is one of the parameters that can be specified in an APPLET tag. It tells the browser where the Java applet is located, and can point to a web site, a third-party server, or to a Java applet stored on the user's own local file system.
By design, an applet always has read access to its own code base - that is, to the folder it came from, as well as to all subordinate folders below it. For instance, if the CODEBASE parameter were used to run a Java applet located in the C:\XYZ folder on the user's system, that applet would have read access to all files in that folder and all child folders below it.

Is CODEBASE part of Internet Explorer or part of the Microsoft VM?
Because APPLET tags are processed by the browser, it's easy to conclude that processing of the CODEBASE parameter is part of Internet Explorer. In reality, though, processing of CODEBASE is handled by the Microsoft VM.

What issues exist with how the VM implements the CODEBASE functionality?
There are two issues that have the same net effect. In both cases, it's possible to construct CODEBASE information that will cause the VM to load an applet from one location but believe that it actually came from somewhere else. In most cases, an attacker would use the vulnerabilities to run a Java applet that came from his or her own web site, but convince the VM that it had actually come from somewhere else - the user's hard drive, a network file share, or some other location.

What would these vulnerabilities enable an attacker to do?
An attacker could use the vulnerability to gain the ability to read files that it should not, by design, be able to access. For instance, if the attacker made it appear that the applet had come from the C:\ folder on the user's system, he or she would gain the ability to read files anywhere in that folder or below. Likewise, if the attacker made it appear that the applet had come from a network share, he or she would gain the ability to read files from that location.

How might an attacker exploit the vulnerability?
The vulnerability could be exploited in exactly the same way as discussed above: by creating a Java applet that exploited it, then hosting the applet as part of a web page that was either hosted on the attacker's web site or sent directly to users via an HTML mail.

Would the attacker be able to change the files?
No. The attacker could only read the files - not add, change or delete them.

Are there any limitations on what files the attacker could read?
Yes. The attacker's access would be governed by the user's own read access. If the user didn't have read access to a particular file, neither would the attacker. This has two important ramifications:

• It would significantly limit the exposure to network file shares. Even though an attacker could potentially gain access to such a share, he or she would still be limited by the user's own permissions. If there were files or folder the user couldn't access, neither could the attacker.
• It would prevent the attacker from accessing some important files on the user's own system. For instance, the Security Access Manager files, which contains encrypted user passwords, is locked by the operating system and cannot be read during operation, even by a user with administrative privileges.

How does the new VM build address the vulnerability?
The patch institutes correct parsing of the CODEBASE information in APPLET tags. In one case, this is done by simply rejecting invalid requests. In the other case, this is done by placing restrictions on when a web page can use the CODEBASE parameter, and only allowing this to happen when the web page and the location of the applet are in the same Internet Explorer security zone.

Domain Spoofing Vulnerability (CAN-2002-1259):

What's the scope of this vulnerability?
This vulnerability could, through a complex scenario, potentially enable an attacker's Java applet to pose as an applet belonging to another web site. Any information the user disclosed to the applet could then be relayed back to the attacker.
Exploiting the vulnerability would require the user to visit the attacker's web site en route to another, presumably trusted, we site, or to click on a hyperlink controlled by the attacker. Even then, the attacker's applet could not compel the user to reveal sensitive information to it. In addition, although the vulnerabilities could be exploited via either a web site or an HTML mail, the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerability?
The vulnerability results because it's possible to create a URL that will cause the Microsoft VM to incorrectly determine the domain from which a Java applet was loaded, and conclude that it came from one web site when in fact it came from another.

What do you mean by a domain?
Domains enable web content to be differentiated based on its point of origination. In most cases, a domain equates to a web site - that is, all of the web pages, Java applets, and other content from Web Site A resides in its own domain, and the content from Web Site B resides in a different one. This allows each site's content to be subjected to the proper security restrictions. Web-based software such as Internet Explorer and the Microsoft VM calculate the domain by scrutinizing the URL from which it was loaded.

How did earlier versions of Microsoft VM calculate the domain?
The VM doesn't correctly parse a particular type of URL. Specifically, if an URL is constructed using a particular, fairly unusual, format containing references to two different web sites, the VM will incorrectly process it and load a Java applet from one site while running it in the other site's domain.

What would this enable an attacker to do?
Effectively, the vulnerability provides an attacker with a means of temporarily replacing a Java applet on someone else's web site with one of his or her choosing. Because it would be located in the other site's domain, it could access any cookies that site had placed on a particular user's system. In addition, any information it solicited from the user could be relayed back to the attacker.

How might an attacker exploit the vulnerability?
The vulnerability could be exploited in exactly the same way as discussed above: by creating a Java applet that exploited it, then hosting the applet as part of a web page that was either hosted on the attacker's web site or sent directly to users via an HTML mail. The attacker's applet would need to have a name that exactly matched that of a valid applet on the other web site.

Suppose the user visited the other site directly. Could the attacker exploit the vulnerability then?
No. The vulnerability could only be exploited if the user visited the attacker's web site (or clicked on a link in an HTML mail from the attacker) en route to the other site. Clearly, this is not the way people normally visit trusted web sites.

Would the effect of exploiting the vulnerability be permanent?
No. For instance, if the user visited Web Site A via the attacker's site on one occasion, the attacker could exploit the vulnerability. But if he subsequently visited Web Site A directly - that is, not via the attacker's site - the correct applet, not the attacker's, would run.

Does the vulnerability provide any way to actually supplant the applet on the other web site?
No. If other users visited Web Site A, the correct applet would run. The attacker's applet would run only in the specific case where a user visited the attacker's web site en route to Web Site A.

How does the new VM build address the vulnerability?
The patch institutes new checks that ensure that the correct domain is calculated, even if the URL is constructed using the format discussed above.

JDBC API Vulnerability (CAN-2002-1260):

What's the scope of this vulnerability?
This vulnerability could enable an attacker to access databases in the guise of another user. If successfully exploited, it would enable an attacker to read, add, change or delete data in any data source the user has access to.
An attacker could only exploit the vulnerability if he or she knew (or could guess) the name of the database. In most cases, this would require significant insider knowledge. In addition, although the vulnerabilities could be exploited via either a web site or an HTML mail, the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerability?
The vulnerability results because the Java Database Connectivity APIs don't properly regulate who can call them, and will service requests from untrusted Java applets.

What are the Java Database Connectivity APIs?
The Java Database Connectivity (JDBC) APIs are a set of functions that allow Java programs to connect to and use databases of various types, including SQL databases, Access databases, and even flat files.

How did the JDBC APIs function in earlier versions of the Microsoft VM?
By design, only trusted programs should be able to access the APIs - after all, they provide the functionality for reading, changing or deleting data. However, the security checks can be bypassed, with the result that an untrusted Java applet could use the APIs.

What would this vulnerability enable an attacker to do?
An attacker who successfully exploited the vulnerability could "hijack" another user's database access privileges. This would enable the attacker to access any data source that the user could access, and make full use of whatever permissions the user had. If the user could delete data, so could the attacker; if the user could add data, so could the attacker; and so forth.

How might an attacker exploit the issue?
The vulnerability could be exploited in exactly the same way as discussed above: by creating a Java applet that exploited it, then hosting the applet as part of a web page that was either hosted on the attacker's web site or sent directly to users via an HTML mail.

How would the attacker know which databases the user had access to?
The vulnerability provides no way for the attacker to learn what data sources the user had access to, or other critical information such as the name and location of those data sources. Instead, it's likely that the attacker would need to conduct significant reconnaissance in order to learn this information.

If the user had only read permissions on a particular data source, could the attacker gain additional permissions?
No. The attacker would be limited to whatever permissions the user had. The vulnerability provides no means by which the attacker could gain additional permissions.

How does the new VM build address the vulnerability?
The new VM build institutes proper checking on the JDBC APIs, and ensures that only trusted code can access them.

Standard Security Manager Access Vulnerability (CAN-2002-1261):

What's the scope of this vulnerability?
This is a denial of service vulnerability. If successfully exploited, it would enable an attacker to temporarily prevent Java applets on other web pages from running. The effect would last for the duration of the current browser session, but new browser sessions would be unaffected.
Although the vulnerability could be exploited via either a web site or an HTML mail, the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerability?
The vulnerability results because the Standard Security Manager can be written to by Java applets.

What is the Standard Security Manager, and what does it do?
The Standard Security Manager is a component of the VM's security policy mechanism, and provides information about the restrictions that should be enforced when Java applets run within Internet Explorer. Among the information it can contain is a list of Java applets and modules that Java applets should not be able to invoke.

What issue did you correct in the Standard Security Manager?
The VM doesn't properly regulate who can write to it. By design, only the VM itself should be able to add information to it. In reality, though, any Java applet can. The upshot is that a Java applet could add other applets to the "banned" list.

What would this vulnerability enable an attacker to do?
An attacker who successfully exploited this vulnerability could add other Java code to the "banned" list in the Standard Security Manager, and prevent the current Internet Explorer session from being able to use that code. The result of doing this would be to prevent any web sites that depended on the now-banned Java modules from operating properly.

How long would the effect of a successful attack last?
The effects would only persist until the user closed the browser. Subsequent browser sessions - or other sessions held in parallel - wouldn't be affected.

How might an attacker exploit the issue?
The issue could be exploited in exactly the same way as discussed above: by creating a Java applet that exploited it, then hosting the applet as part of a web page that was either hosted on the attacker's web site or sent directly to users via an HTML mail.

Could the attacker use the vulnerability to loosen restrictions on his or her own Java applets?
No. The vulnerability would only allow the attacker to impose stricter restrictions; it wouldn't provide any way to loosen them.

How does the new VM build address the vulnerability?
The new VM build corrects the permissions on the Standard Security Manager, in order to allow only the VM itself to write to it.

User.dir Exposure Vulnerability (CAN-2002-1325):

What's the scope of the first security issue?
This is an information disclosure issue. If successfully exploited, it would enable an attacker to learn someone else's user name. While this would not by itself pose any security risk to the user, it could aid an attacker in performing reconnaissance for other attacks.
Although the vulnerability could be exploited via either a web site or an HTML mail, the email vector would be blocked if the user were running any of several mail clients. Specifically, Outlook Express 6 and Outlook 2002 (which ships as part of Office XP) disable Java by default, and Outlook 98 and 2000 disable it if the Outlook Email Security Update has been installed.

What causes the vulnerability?
The issue results because the Microsoft VM doesn't prevent untrusted applets from accessing the user.dir system property.

What are system properties?
When a Java applet runs, it may need to know certain information about the user's system in order to do so correctly. For instance, if an applet will require assistance from the operating system to do its job, it will likely need to know exactly what version of Windows is installed on the system it's running on. System properties provide the means through which applets can query the operating system and learn such information.
Different properties have different levels of sensitivity, and some are not appropriate for untrusted applets. By design, the Microsoft VM should regulate which properties are available to a particular applet, based on whether it's trusted or not. However, it fails to regulate access to one particular system property, known as user.dir.

What is user.dir and what does it do?
The user.dir property provides information on the current working directory of the hosting application - in this case Internet Explorer.

Why isn't it appropriate for an untrusted applet to learn Internet Explorer's current working directory?
The primary reason is because it can divulge the user's account name. In most cases, Internet Explorer's working directory is the user's desktop, which includes the user name as part of the path. For instance, the desktop for user John could be "c:\documents and settings\john\desktop". By divulging the directory, the VM would also have divulged the "John" user name.

Would the issue let the attacker know the user's identity?
No. There is an important distinction between a user's identity and their username. The username is simply the name by which Windows knows the system - but it's not necessarily the user's real name. For instance, the owner of the John account might indeed be named John, but there's no guarantee. Home users can select any username they like; corporate users may be required to select a username that's some derivation of their real name.

How might an attacker exploit the vulnerability?
The issue could be exploited in exactly the same way as discussed above: by creating a Java applet that exploited it, then hosting the applet as part of a web page that was either hosted on the attacker's web site or sent directly to users via an HTML mail.

How does the new VM build address the vulnerability?
The new VM build imposes restrictions that will prevent untrusted Java applets from accessing the user.dir system property.

Incomplete Java object Instantiation Vulnerability (CAN-2002-1263):

What's the scope of this vulnerability?
This vulnerability could provide a way for an attacker to cause Internet Explorer to fail when a user visited the attacker's web site. This would not by itself pose any security risk to the user, and normal operation could be restored by restarting Internet Explorer.

What causes the vulnerability?
The vulnerability occurs because it is possible for a Java applet to create an incorrectly initialized Java object, the effect of which would be to corrupt memory in Internet Explorer and cause it to fail.

What do you mean by "an incorrectly initialized Java object"?
When a web page causes Java code to be loaded and run (or when a Java applet causes additional Java code to be loaded and run), it's known as instantiating a Java object. Several housekeeping activities have to take place when this is done, in order to allocate the resources that the code will need. This issue involves a way of instantiating Java objects that cause them to be started without all the proper resources.

How were Java objects instantiated by earlier versions of the Microsoft VM?
It's possible for a web page to instantiate a Java object through a method that should, by design, not be allowed.. The Microsoft VM doesn't block instantiation of a particular type of system-provided Java object - specifically, ones that contain so-called private constructors. Such objects should only be creatable by the VM itself; web pages and Java applets lack the authority to allocate resources for them.

What would this issue enable an attacker to do?
An attacker could use this issue to cause Internet Explorer to fail on a user's system.

What would be required to restore normal operation?
To resume normal operation, the user would only need to restart Internet Explorer.

I heard that this was actually a buffer overrun vulnerability. Is this true?
There have been a number of speculative statements suggesting that this is a buffer overrun vulnerability, through which an attacker could gain control over a user's system. In fact, this is not a buffer overrun and, to the best of Microsoft's knowledge, it could not be used to do anything except make Internet Explorer fail.

How does the new VM build address the problem?
The patch addresses the problem by blocking the instantiation scenario discussed above, and disallowing instantiation of Java objects that have private constructors.

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.