A couple of serious security flaws in Microsoft's Internet Explorer were announced over the weekend.

Microsoft has patched these problems. (See http://www.microsoft.com/security.) But are these just sticking-plaster fixes for larger issues faced by Internet users, whether or not they use Microsoft technologies?

The first flaw, the Virtual Machine Sandbox, was discovered by The Princeton Secure Internet Programming (SIP) team (www.cs.princeton.edu/sip/index.php3), in collaboration with Drew Dean at Xerox PARC and Dan Wallach at Rice University. They noted a coding flaw within one of Microsoft's Java class libraries, that allows maliciously crafted applets to escape the security "sandbox" that normally restricts Java applets from acting on end-user systems.

The scary part about this vulnerability is that the malicious applet can be attached to any HTML code delivered via Web page or e-mail and: "does not require the user to do anything beyond viewing the Web page or e-mail," according to members of the SIP team.

Anti-Microsoft sloganeers, who will seize this opportunity to disparage IE, should note that a flaw in the "true" Java Virtual Machine (JVM) (i.e. Sun's) was revealed back in April. (Microsoft's JVM was not vulnerable to this attack.) This issue affected several then-current versions of the JVM, including Sun's Java Development Kit 1.1 and 1.2, and Netscape's Navigator 4.x.

Which leads to our larger point. These flaws completely violate the design principles of Java; so how did they come about? The answer is the source of many product-security vulnerabilities: A flawed implementation of a secure design is just as insecure as a flawed design. In other words, don't assume that Java's sandbox will save you from everything. One of Microsoft's suggested solutions – to disable IE's Java support entirely – is the only absolute way to be sure in the long run. We won't touch the marketing implications of this with a 10-foot pole, however. It's clear that users and administrators alike must keep up-to-date on JVM security flaws.

The second flaw has two parts, Scriptlet.typelib and Eyedog, which are separate ActiveX controls that computer consultants identified as potential security problems. (Georgi Guninski illustrated the Scriptlet.typelib issue, and Shane Hird, Adrian O'Neill, and Richard M. Smith were cited for bringing the Eyedog issue to Microsoft's attention.) They share a thread, however: They are both flagged as "safe for scripting," so IE does not ask users whether they want to load the controls before executing them. This is not good, because Scriptlet.typelib allows the changing, or deleting, of files, and Eyedog can collect information from the Registry. Oh, yes, and Eyedog has a known buffer overflow condition that can run arbitrary code.

The interesting thing about these problems is that Microsoft is still clinging to the notion that anyone who uses Microsoft products can trust ActiveX developers. This is especially disconcerting, given the growing number of ActiveX controls being developed by third parties. In a CNN interview, Smith, also one of the founders of development tool vendor Phar Lap Software, noted that ActiveX controls are becoming commonplace in software that ships with pre-configured computers. He likens these pre-installed controls to "accidental Trojans". It seems obvious to us that the Scriptlet.typelib and Eyedog holes would be better addressed by barring developers from setting the "safe for scripting" flag for any ActiveX control – period.

Doom and gloom is part and parcel to the security industry, and we hope we haven't portrayed Java or ActiveX as the source of the millennial security debacle. However, we've encountered those who think they are.