The component war heats up - ActiveX, Java becoming more alike - Technology Information

Software Magazine, May, 1997 by George Lawton

As corporate software developers begin to use the Web and corporate intranets to deliver component-based business applications, they will be faced with choosing between developing with Windows-based ActiveX controls from Microsoft Corp., Redmond, Wash., and platform-independent Java applets from Sun Microsystems Inc., Mountain View, Calif.

Like most technologies, ActiveX and Java have their pros and cons.

Microsoft's ActiveX controls evolved from the com- pany's earlier Object Linking and Embedding (OLE) technology. ActiveX enables de- velopers to create standalone applications and components that can be run over a corporate network, intranet or the Internet. The technology uses Microsoft's Component Object Model (COM) to communicate across a desktop and its Distributed Component Object Model for communication over networks.

Java, of course, is the component development language developed by Sun Microsystems and managed by its subsidiary, JavaSoft. Like ActiveX, it can be used to develop applets that can run across a network. Java's strength is that it can run on a wide variety of hardware and operating system platforms. Its key weakness is that it does not support as many features as ActiveX, and is somewhat slower than running compiled code.

Both ActiveX and Java are new, immature technologies. As a result, both must still add security features before they can be used confidently in electronic commerce applications. One drawback to allowing network-based components into an enterprise is that they can introduce a new security hole into the system. For example, once a user has accepted an ActiveX control, it has free reign over all of the system's resources. ActiveX components can access hard drives, peripherals and local-area networks to perform all of the operations required by them. The benefit is that ActiveX applications can be extremely robust. They can perform sophisticated operations without requiring any assistance from the user. The danger, however, is that a hacker could implant a Trojan horse or virus program in an ActiveX component and use it to attack a company's IT assets.

There have already been a number of well-publicized examples of such attacks. Fred McLain, president of Apropos Inc. in Kirkland, Wash., recently posted the Exploder ActiveX control on the Internet to illustrate ActiveX flaws. This program can shut down a computer as soon as it is downloaded from the Internet. There's more: A group of hackers in Germany associated with the Chaos Computer Club developed an ActiveX control that, innocently enough, lets a user play a game. But in the background, it searches out the Quicken accounting program on the hard drive, adds an extra transaction to the registry of electronic bills to be paid, and deletes the record of the transaction after it has been processed. The Chaos control could conceivably be used to empty the checking account of an unwitting electronic banking customer.

Microsoft counters that any malevolent programs that can be built with ActiveX technology can be controlled and audited with its Authenticode technology. Authenticode allows a developer to sign a control when they complete it in order to certify that they made it themselves. When a user requests an applet, the browser checks the applet's signature before proceeding.

With Microsoft's Internet Explorer, users can set the level of security they want. If they only want to download controls that have been signed by well-established firms, they could set security to the highest level. On the other hand, if they want to download any applet, regardless of whether it has been signed, they would set security at its lowest setting. The keys for certifying software are managed by VeriSign Inc., Mountain View, Calif., a spin-off of encryption developer RSA Data Security.

While this approach does make it more difficult to develop malicious controls, it still has a few flaws. The process for acquiring a license is fairly simple and can be done by just about anyone, including hackers. When such people sign their malicious code, it looks to the user like any other control and can be run without raising any security concerns. After the fact, Authenticode can be used to track down the developer and decertify them, but it does nothing to prevent attacks in the first place. The hacker would not necessarily even have to apply for their own key. As Authenticode technology grows in acceptance, it is not unreasonable to assume that some keys may be stolen and traded by hackers. They may be physically copied or electronically pilfered as they are sent down the Internet. It is noteworthy that the keys used by well-established software vendors require a physical encryption "dongle," or hardware key, that plugs into the back of the PC. Since the dongle can be physically locked in a safe, and its absence quickly noted by the vendor, this system affords a higher level of security than that offered by applets signed by individuals.

Java applets do not have this same security flaw because they are run in an isolated "sandbox" that does not have access to system resources. Consequently, it is far more difficult to write viruses that crawl through a computer network via Java. Unfortunately, there's a big downside to the Java sandbox: These applets have far less control over system resources than ActiveX components, which makes it more difficult to run programs that need to use a hard drive and peripherals attached to a computer.