While the Internet has provided a great boon for businesses, it's also created a wealth of opportunity for the virus writer and other developers with malicious intent. New technologies, such as Java and ActiveX, create fresh environments that hackers can potentially exploit. Luckily, while there has been a lot of press given to potential security problems with these and other Internet technologies, to date there are no documented "in-the-wild" attacks based on Java or ActiveX. All the demonstrations have only been in the lab.
To understand the Java and ActiveX threat, it's necessary to understand the distinction between a software virus and a software Trojan horse. The difference between viruses and Trojan horses is primarily in the way they are spread. Viruses contain code to replicate and spread themselves without the user being aware of the distribution. For example, a virus may rewrite a section of the boot sector so that each time a user boots their machine, the virus copies itself into memory to intercept certain actions such as reading from a diskette. Subsequently, each time a diskette is read from, the virus will copy itself onto the boot sector of the diskette, enabling it to be spread to the next machine.
Trojan horses, on the other hand, contain no specific code to replicate. They rely on the writer placing them somewhere and enticing the unsuspecting user to execute them.
Since virus replication creates the potential to cause widespread damage, companies are concerned about protecting their machines. Historically, while Trojan horses have the potential to cause damage, their lack of replication means that the damage will always be in a contained environment. However, the Internet has changed all that by enabling widespread, quick distribution of potentially dangerous Java or ActiveX Trojan horses.
Java and ActiveX are both technologies that are being touted as the best way to make Web pages interactive and more functional than existing technologies allow. Java, by virtue of the fact that it runs inside a virtual machine on the client desktop, contains its own security model that creates a relatively protected environment.
Since Java is just a programming language, a developer can write any kind of stand-alone application in Java. As long as the user runs it within a Java interpreter, the application can do anything that one would normally expect out of an application written in any other language. The security comes from the fact that, as any other application, the user needs to invoke the application from his local machine and is in control of launching it.
Applets are special types of Java applications that are designed to run within a browser, whether they are downloaded from the Internet or not. Downloaded applets have a different security policy to those that are run from the local machine, even if they are run within the same browser.
Each applet, viewer or browser has a Security Manager object built into it that enforces the security model for that particular browser. Netscape and Microsoft generally follow the same conventions for applets that Sun recommends, but they do vary in implementation since each security object is independently developed. It's very likely that these policies will change as more Java applets are developed and the security restrictions start to limit functionality that users really want. In fact, Sun's JDK 1.1 applet viewer allows applets to read and write external files in certain circumstances.
For now, downloaded applets have the following restrictions:
Downloaded applets are loaded into the virtual machine via a class loader, which is responsible for isolating the applet and running it through a bytecode verifier. The verifier checks for purposeful violations of Java language rules that might cause the virtual machine to crash and thereby give a virus access to the local machine.
Applets that are loaded from the local file system from a directory in the user's CLASSPATH have none of the above restrictions! These applets have the implicit trust of the application that launched it. So there is a big difference between having an applet loaded as part of a Web page and downloading the applet as a file and running it locally. Running a downloaded applet locally is as dangerous as running any other random downloaded executable whose history isn't known.
ActiveX is Microsoft's original response to the Java juggernaut. Essentially a slimmed down version of OLE, ActiveX provides developers a way to download small executable objects that can be invoked directly on the user's machine. ActiveX controls (OCXs) also allow rapid development of applications based on "reusable parts." Unlike Java, there is no inherent security model for ActiveX. OCXs are fully executable pieces of Windows code that have no restrictions placed on them once they reach the client machine, regardless of how they got there. This creates a potentially enormous hole for viruses to travel through as Web pages can cause the download and execution of an OCX with no interaction by the user.
Microsoft's Internet Explorer offers the option of blocking the download of ActiveX controls and/or prompting the user to allow the download of each control. Additionally, Microsoft has created an ActiveX signing initiative called Authenticode where each applet is digitally signed with a Verisign certificate to verify the author of the control. If an applet is signed, the browser informs the user who the author was and, if they trust the author, lets them download the control. Unfortunately, unless the browser is set to block OCXs, an unsigned control passes through unchecked. Microsoft is hoping that all legitimate authors will sign their controls and only nasty controls won't be signed.
The most effective way to prevent infection or damage from unknown ActiveX or Java applets is to disable downloads in the browser. Many companies do block Java from coming through their firewall. Unfortunately, this also restricts some potentially useful applets as well. For users who are sophisticated enough to make intelligent decisions about the origins of applets, setting the browser to prompt on download is an alternative.
To date, no known Java or ActiveX viruses or Trojan horses exist in the wild. Dr. Solomon's is currently working on extending our technology to scan Java applets for viruses as the bytecodes are being downloaded. We are also altering our existing OLE scanning technology to recognize ActiveX controls as they are written so that when the first Java or ActiveX virus is found, Dr. Solomon's Anti-Virus Toolkit will be there to detect it.
[Back to index] [Comments (0)]