Microsoft Security Bulletin MS02-069

Flaw in Microsoft VM Could Enable System Compromise (810030)

Originally posted: December 11, 2002

Summary

Who should read this bulletin: Customers using Microsoft« Windows«.
Impact of vulnerability: Eight vulnerabilities, the most serious of which would enable an attacker to gain control over another userÆs system.
Maximum Severity Rating: Critical
Recommendation: Customers should install build 3809 or later of the Microsoft VM, as discussed below.
Affected Software:

Versions of the Microsoft virtual machine (Microsoft VM) are identified by build numbers, which can be determined using the JVIEW tool as discussed in the FAQ. All builds of the Microsoft VM up to and including build 5.0.3805 are affected by these vulnerabilities.

End User Bulletin: An end user version of this bulletin is available at: http://www.microsoft.com/security/security_bulletins/ms02-069.asp

Technical details

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:

Severity Rating

COM Object Access Vulnerability Critical

CODEBASE Spoofing Vulnerabilities Important

Domain Spoofing Vulnerability Moderate

JDBC API Vulnerability Moderate

Standard Security Manager Access Vulnerability Low

User.dir Exposure Vulnerability Low

Incomplete Java object Instantiation Vulnerability Low

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: CVE-CAN-2002-1257
CODEBASE Spoofing Vulnerabilities: CVE-CAN-2002-1258
Domain Spoofing Vulnerability: CVE-CAN-2002-1259
JDBC API Vulnerability: CVE-CAN-2002-1260
Standard Security Manager Access Vulnerability: CVE-CAN-2002-1261
User.dir Exposure Vulnerability: CVE-CAN-2002-1325
Incomplete Java object Instantiation Vulnerability: CVE-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.

Frequently asked questions

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:

Select Start, then Run.
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.

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:

Select Start, then Run.
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.
In the result command box, type ôJviewö (without the quotes) and hit the enter key.
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.

If the version number is. . . You should. . .

3805 or less Apply Microsoft VM build 3809. (Available from Windows Update).

3805 plus MS02-052 patch released in September 2002 Apply Microsoft VM build 3809. (Available from Windows Update).

3809 or higher Do nothing. YouÆre using a version thatÆs already protected against these vulnerabilities.

IÆm a network administrator. I see that the patch is available on Windows Update, but IÆd like to download it and update the Microsoft VM on my usersÆ systems. Can I do this?
Yes. You may update existing Microsoft VMs by following these steps:

Go to the Windows Update web site.
In the left pane, under Other Options, select ôPersonalize Windows Updateö.
Under ôSet Options for Windows Updateö, select the checkbox for ôDisplay the Link to Windows Update Catalog under æSee AlsoÆö, then click ôSave Settingsö.
Go back to the Windows Update web site.
In the left pane, under ôSee Alsoö, select ôWindows Update Catalogö.
Select ôFind Updates for Microsoft Operating Systemsö.
Select the operating system and language of your choice.
Select ôCritical Updates and Service Packsö.
Select all of the patches youÆd like to download, then click on ôGo to download basketö to download them.

For more information on using the Windows Update Catalog, please see the following references:

Windows NT 4.0: Microsoft Knowledge Base Article 313191.
Windows 2000: Microsoft Knowledge Base Article 326426.
Windows XP: Microsoft Knowledge Base Article 326426.
All other operating systems: Microsoft Knowledge Base Article 810030.

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.

Patch availability

Download locations for this patch

The patch is available to update existing Microsoft VMs via the Windows Update web site.

Note: A version of the patch that can be downloaded and deployed throughout a network is available. Information on obtaining it is available in the FAQ.

Additional information about this patch

Installation platforms:
The new VM build can be installed to update Microsoft VMs on the following versions of Windows:

Microsoft Windows 95
Microsoft Windows 98 and 98SE
Microsoft Windows Millennium
Microsoft Windows NT 4.0, beginning with Service Pack 1
Windows 2000 Service Pack 2 or Service Pack 3
Microsoft Windows XP Gold or Service Pack 1.

Inclusion in future service packs:
The fixes included in this build will be included in all future VM builds.
Reboot needed: Yes
Patch can be uninstalled: No
Superseded patches: The new VM build supersedes all builds prior to and including 5.0.3805 It includes fixes for all issues discussed in the following Microsoft security bulletins:

MS99-031
MS99-045
MS00-011
MS00-059
MS00-075
MS00-081
MS02-013
MS02-052

Verifying patch installation:
Knowledge Base article 810030 provides information to verify that you've installed the patch.
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
Caveats:
None
Localization:
Localized versions of this patch are available at the locations discussed in ôPatch Availabilityö.
Obtaining other security patches:
Patches for other security issues are available from the following locations:

Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Support:

Microsoft Knowledge Base article 810030 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
Disclaimer:
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
Revisions:

V1.0 (December 11, 2002): Bulletin Created.
V1.1 (December 12, 2002): FAQ updated to provide additional references regarding using the Windows Update Catalog.