Three recently discovered flaws in the Microsoft Virtual Machine can open client systems to complete compromise, according to a report by Symantec.
One vulnerability allows attackers to remotely execute DLLs by exploiting Microsoft’s implementation of a Java Virtual Machine, which is used to run Java code in Windows. The second vulnerability results from a failure to properly validate input, allowing malformed data to force a system shutdown. The third risk involves XML and lets an attacker run code normally restricted to trusted applications.
Microsoft Security Bulletin MS02-052 lists the vulnerabilities as follows:
- DLL execution via JDBC classes: CVE-CAN-2002-0866
- Handle validation flaw: CVE-CAN-2002-0867
- Inappropriate methods exposed in XML support classes: CVE-CAN-2002-0865
Details about the vulnerabilities’ precise mechanisms are available in MS02-052, if you want to dig a little deeper into the issue. However, the critical point here is that you should strongly consider fixing this Microsoft VM flaw, since the attacks can be triggered so easily and so many Windows systems may be affected by these vulnerabilities; if your users access the Internet or open HTML e-mail, you are at risk.
Risk level: Potentially critical
According to Microsoft, the threats posed by these vulnerabilities range from low to moderate severity for servers and low to critical for client systems.
Applicability: Most Windows versions
These vulnerabilities are found in every Microsoft Virtual Machine associated with Internet Explorer versions 4.0 through 6.0, including versions for every operating system from Windows 95 through XP (even those with service packs installed). Basically, the Microsoft VM vulnerability affects almost everyone.
Symantec specifically lists the following Microsoft VM series as being affected by these vulnerabilities:
Very few Windows systems don’t have a Microsoft VM installed. Although it doesn’t seem to be mentioned specifically in any of the current reports, I know from personal experience that some Windows XP Professional installations don’t include the Microsoft VM, but you’ll probably already know if this is the case because such systems will present Get Error messages when they can’t run the Java applets present at many Web sites.
If you have any doubt about whether you have Microsoft VM installed, simply open the Command Prompt interface on your Windows system and try to run JVIEW. You’ll know that Microsoft VM is not installed if you see a response such as:
‘jview’ is not recognized as an internal or external command, operable program or batch file
You’ll probably see this report if you are running Windows XP Version 5.1.2600.
If the Microsoft VM is installed, running JVIEW should produce a list of the command line options available for running JVIEW, starting with this line:
Microsoft ® Command-line Loader for Java Version X.XX.XXXX
The last four numbers of this line are the version number, which is important to note as you evaluate fixes.
The major mitigating factor listed in MS02-052 is that users who have disabled Java code are not vulnerable. Systems configured to open sites and HTML e-mails in The Restricted Zone would fall into this safety net.
If users follow good practices and don’t visit unauthorized Web sites, then exploitation of these vulnerabilities is unlikely. Firewalls set to block mobile code can also reduce your risk.
You can avoid these vulnerabilities by disabling Microsoft VM, but this is impractical for most users. Depending on your installed Java Version number, you can take one of the following actions:
- If your Java Version number is lower than 3805, you’ll need to undertake a two-step process to patch the system. First, update to Microsoft VM 3805 and then apply the patch for version 3805 from Windows Update. If you have version 3805 already, simply install the patch.
- If your version number is higher than 3805, your Microsoft VM is not vulnerable to these three threats and you don’t need to do anything. However, this is unlikely since 3805 was still the current Microsoft VM version in late September 2002.
Although Microsoft lists a number of mitigating factors, most of them boil down simply to this: If you don’t use Java, you aren’t vulnerable. I don’t know about you, but that doesn’t offer me much comfort. In fact, the lack of Microsoft VM on my XP Pro system has caused me a number of problems.
The bottom line is that most Windows systems use Java and are at risk. So, administrators need to patch and/or update most of their systems.